So there are several motivations for this design. We use the Play Framework 
and it comes with a *Database* interface that our *AppDatabase* implements. 
Play uses Guice for DI, so that AppDatabase class is injected where needed.

I actually got to thinking and slightly changed my use of ExecuteListener. 
So what I did now is add a *withTransaction* method to *AppDatabase* that 
takes an ExecuteListener as follows

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()))
                                 ));
        });
    }



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.

Reply via email to