Skip to content
This repository has been archived by the owner on Jul 5, 2023. It is now read-only.

Is it possible to work with JdbiBundle and JdbiRepository with multiple databases #85

Open
leobastiani opened this issue Oct 11, 2021 · 2 comments

Comments

@leobastiani
Copy link

leobastiani commented Oct 11, 2021

I have a dropwizard-guicey application with two databases and I wish I could use two JDBI and repositories like so

@Override
public void initialize(final Bootstrap<Configuration> bootstrap) {
  bootstrap.addBundle(
      GuiceBundle.builder()
          .enableAutoConfig(getClass().getPackage().getName())
          .bundles(
              JdbiBundle.<Configuration>forDatabase(
                      (conf, env) -> conf.getApplicationDataSourceFactory())
                  .withPlugins(new H2DatabasePlugin()))
          .bundles(
              JdbiBundle.<Configuration>forDatabase(
                      (conf, env) -> conf.getSessionDataSourceFactory())
                  .withPlugins(new H2DatabasePlugin()))
          .build());
...

Would I need to change these lines?

@xvik
Copy link
Owner

xvik commented Oct 11, 2021

Out of the box, it is not possible. The problem is that the current implementation is pretty tightly bound to the single jdbi instance. In order to implement multiple db support, you'll have to change almost all parts.

I will describe how repositories work now.

This part is required to overcome guice limitation (not possible to bind abstract type) - guice would be able to create instances of these generated classes (not abstract anymore) and bind these instances into repository injection points. It was done like this to be able to apply any AOP interceptors (which is impossible for object instances: e.g. if I were using direct jdbi proxy bindings, transactional annotations would not work on proxies).

To make the repository work properly, AOP interceptor is registered for each repository type.
So any call to dummy guice object is intercepted and redirected to real jdbi proxy instance (lazily created).

You would need to modify lazy proxies provider: for example, you may introduce custom annotations and use them to resolve proper jdbi instance.

In the current implementation, a single jdbi instance is bound in guice module. You'll need your own version of guice module. Probably It would register different jdbi instances using annotation as a qualifier.

The next problem would be transactions support: currently, AOP interceptor wraps all @InTransaction annotations and manage the transaction. With multiple jdbi instances, transactions could also be different (different scopes). But for simplicity, you can always start/stop all of them at once (or use marker annotations, but it would be harder to implement).

For sure, there would be other problems, it was just raw points.

It's not the first time when I asked about multiple db support, but it's not easy to implement in the general case. I'm thinking about more or less universal abstraction for a long time, but can't find enough time to work on it (always something more important appears). Hopefully, someday I'll find enough time.

@dtrott
Copy link

dtrott commented Dec 13, 2022

I have been able to successfully use 2 Hibernate bundles in the same Guicey/Dropwizard application.

Assuming that you have one primary datasource (that represents the majority of your code) and a second "minor" datasource. You might be able to workaround the issue using some combination of:

  • 1 JDBI bundle
  • Some hand code JDBI (not using SQLObjects)
  • A/some Hibernate bundle(s)
  • Raw JDBC

Obviously your choice will depend upon your relative preferences for using different data access technologies and/or willingness to write a bunch of boilerplate.

PS @xvik Thanks for the response I was about to look into using two JDBI datasources myself - its good to have the definitive answer so I can pivot to one of the above approaches.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants