Hi Lukas,

The issue is on my side, and i need some advice on how to resolve it. I am
currently using Jooq with Dropwizard.

So the jooq configuration is created at app launch and then injected into
my services, so the configuration is global across the app.

Now introducing the caching layer i have to include MockDataProvider

*Original jooq connection*

DSLContext create = DSL.using(configuration)

*Jooq with caching*

configuration.set(new DefaultVisitListenerProvider(new
CacheVisitListener()));
configuration.set(new MockConnection(new
ResultCache(configuration.connectionProvider().acquire())));
return DSL.using(configuration);

Now since the configuration is global, i think because of the
MockConnection object whenever i insert an UpdatableRecord the primary key
id is null. As a result my test cases are failing.

How do i overcome this issue? is there a way for me to create a new
connection from the original one and is that a good idea?

Regards,
Sheldon

On Tue, Aug 11, 2015 at 8:45 PM, Lukas Eder <[email protected]> wrote:

> Hello Sheldon,
>
> Thank you very much for the feedback. Great to know that it has worked for
> you.
>
> Yes, VisitListener (and all the other SPI like ExecuteListener) also apply
> for Record.store(), Record.insert(), etc. as these store(), insert(),
> methods are just convenience to access the more general SQL API, such as
> DSLContext.insertInto(...).values(...).execute();
>
> Now, there are two possibilities here:
>
> 1. You have discovered a bug in jOOQ
> 2. You have discovered a flaw in that VisitListener implementation by
> Aakash or in the adaptations that you may have made.
>
> I guess I would need to see a fully reproducible test case to be sure on
> my side. Did you continue investigating, e.g. by debugging?
>
> Cheers,
> Lukas
>
> 2015-08-11 13:34 GMT+02:00 <[email protected]>:
>
>> Hi Lukas,
>>
>> I tried the technique provided by Aakash, and it works well. But i have
>> come across another issues.
>>
>> Since the above method uses a custom VisitListener, does this have any
>> effect on record inserts?. I am currently facing the issues with a null id
>> returned when a record is stored in DB.
>>
>> e.g record.store() the autoincrement id is null, but if is switch back to
>> the original VisitListener things work fine.
>>
>> Am i missing something here?
>>
>> On Saturday, August 10, 2013 at 12:48:59 PM UTC+5:30, Lukas Eder wrote:
>>>
>>> Hello Aurélien,
>>>
>>> 2013/8/10 AurĂ©lien Manteaux <[email protected]>
>>>
>>>> Hey Lukas,
>>>>
>>>> Thank you for your quick answer !
>>>>
>>>> I'll take your advice and try to write a cache close to jdbc, your
>>>> solution with jOOQ MockConnection seems promising.
>>>> I will also wait for the new SQL rendering and variable binding SPI to
>>>> enable the cache to be correctly cleared.
>>>>
>>>> As soon as I have something working, I will share it here !
>>>>
>>>
>>> Great! Feature requests and improvement hints to the MockConnection are
>>> very welcome, too!
>>>
>>> Cheers
>>> 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 a topic in the
> Google Groups "jOOQ User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jooq-user/xSjrvnmcDHw/unsubscribe.
> To unsubscribe from this group and all its topics, 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.

Reply via email to