Hi Max, OK, I see - that's very nice and transparent. Good to see lambdas in action for such transaction scope!
Cheers, Lukas 2015-12-04 16:54 GMT+01:00 Max Kremer <[email protected]>: > So there are several motivations for this design. The primary one is that > we use Play Framework which uses Guice for DI. The Database interface we > implement comes from Play and our AppDatabase implementation is injected > where needed. It's not really about transaction management; there are > withConnection methods analogous to the withTransaction method I pasted > above. > > This got me thinking.... I've since changed my implementation of how I use > ExecuteListener. I've added a method to our AppDatabase class that takes an > ExecuteListener: > > public class AppDatabase implements Database { > > ... > > public void withTransaction(ExecuteListener executeListener, > BiConsumer<Connection, DSLContext> block) { > db.withTransaction(c -> { > block.accept(c, DSL.using(DSL.using(c, SQLDialect.POSTGRES_9_4, > settings) > .configuration() > .derive() > .set(new > DefaultExecuteListenerProvider(new PostgresParamListener())) > )); > }); > } > > > And I use it like this wherever I need my special behaviour: > > db.withTransaction(new PostgresParamListener(), (c, d) -> { > > ...d.select(.... > > }); > > > > > > > On Friday, December 4, 2015 at 3:08:45 AM UTC-5, Lukas Eder wrote: >> >> Hi Max, >> >> 2015-12-03 23:44 GMT+01:00 Max Kremer <[email protected]>: >> >>> Hi Lukas, >>> >>> Thanks for the tips. I played around with putting my logic in >>> different overridden methods of *DefaultExecuteListener* . >>> >>> By watching a live log on what the DB is doing I can see that I'm >>> getting the effect I want by overriding *prepareStart *( to add the >>> param ) and *executeEnd *(the reset the param) >>> >> >> Great, glad that it's working now, for you! >> >> >>> Your approach for configuring the *DSLContext* at the time of calling >>> *DSL.Using* wont work well for us because we do stuff like this. >>> >>> >>> public class AppDatabase implements Database >>> { >>> ... >>> >>> public <T> T withConnection(BiFunction<Connection, DSLContext, T> block) >>> { >>> return db.withConnection(c -> { >>> return block.apply(c, DSL.using(c, SQLDialect.POSTGRES_9_4, >>> settings)); >>> }); >>> } >>> >>> >>> >> I see - yes, when you're using that convenience API that constructs a >> Configuration internally, you won't be in full control of all >> Configurations that are ever created. I wonder if that's a common situation >> with jOOQ usage... >> >> I'm curious about the db.withConnection() logic. There might be a >> use-case from which we could learn. What's behind it? Is this your >> transaction layer implementation? >> >> Best >> Lukas >> > -- > You received this message because you are subscribed to the Google Groups > "jOOQ User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
