jdbi

jdbi copied to clipboard

1. From the doc it is not clear that you have to use the JdbiUtil class for the declarative transaction management to work. This becomes only apparent if you look at the test code. You would excpect everything to work automagically after you set up your FactoryBean and inject Jdbi.
2. The FactoryBean is probably only useful if you setup spring via xml (since it offers some fast-config params). Since a lot of ppl nowadays use java-config only the doc maybe should reflect that (even if it is actually trivial)

Other than that i was asking myself if the plugin should maybe offer a JdbiBean, or something like that, which has the same interface as jdbi but delegates calls to an underlying jdbi instance and handles transactions itself. That way you would not need to use JdbiUtil or anything like that but use jdbi the way you are used to while in the background spring handles transactions for you - makes sense?

Am willing to work on this issue if needed

I don't use Spring at $WORK so I'm only I'm only vaguely aware of Spring conventions.

Would providing a JdbiBean class provide any advantage above and beyond e.g. a @Bean Jdbi jdbi() method in a @Configuration class in the user's app?

Maybe all this needs is an example in the docs using java config, with a blurb on how to set up Jdbi to work with Spring's container-managed transactions.

you are right, in java config this is rather trivial as you outlined it. but you would still need some undocumented static access to a "util" class to get any benefit out of spring

for clarification: this is how I envisioned it

@Bean public Jdbi jdbi() { return new org.jdbi3...jdbi-spring.TransactionAwareJdbiBean(); }

where that implentation is a subclass of Jdbi delegating all calls to super BUT rerouting all calls involving a handle to some implementation with JdbiUtil's transaction management.

simply put: to set up a jdbi bean but then not beeing able to use it directly when injected (but rather make some static calls) is not the 'spring' way I think.

Jdbi isn't really intended to be subclassed--that's why it has a private constructor.

I think we'd be better off with a builder-style utility class e.g. SpringJdbiBuilder with spring-centric chaining builder methods to set up specific things, like e.g. container managed transactions. If Spring needs a new hook to control some internal behavior in Jdbi, I think we could accommodate that.

I think we should definitly accommodate that. Imho spring-jdbi should be a dropin replacement for spring-jdbc - it would definitly boost acceptance in spring managed environments.

That being said, maybe its best to provide an JdbiTemplate class similar to springs JdbcTemplate (only similar in name). That class would have an underlying Jdbi instance, and all relevant methods Jdbi used for querying (useHandle withHandl... maybe even NO inTransaction, etc.).

If this solution is accepable/preferred it would be nice to have a common (small) interface between Jdbi and JdbiTemplate which would just consist of useHandle and withHandle and open (which may be used to bypass spring transaction management) which could be called JdbiActions or something like that.

Just putting my thoughts out there...

I'm not sure I understand -- why is being a drop-in replacement for spring-jdbc a goal? If you're writing against spring-jdbc's interface already, then it seems like you have almost nothing to gain by adding an additional middle layer before the JDBC driver.

As far as a JdbiTemplate, it sounds like it wraps a Jdbi and copies its public interface -- so it's just a delegate. Doesn't that mean you could simply use Jdbi as is and eliminate the additional layer of abstraction, or have I missed some essential feature that cannot be implemented in another way?

I think I will do a PR to clarify - its basically just a convience feature I implemente for my project. Furthermore the plugin needs rework/fixing anyways I am afraid since I just observed that the JdbiUtil.Adapter does not cleanup the used resource after completion - will open a seperate issue

It would be great to find someone that is really versed in the spring universe to take a look at our current spring support.