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] <javascript:>>
> :
>
>> 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.
