Hi Lukas, Thanks for the response.
On Tue, Sep 5, 2017 at 9:34 PM, Lukas Eder <[email protected]> wrote: > Hi Kamal, > > 2017-09-05 17:26 GMT+02:00 Kamal raj <[email protected]>: > >> On Tue, Sep 5, 2017 at 12:54 PM, Lukas Eder <[email protected]> wrote: >> >>> *In your particular example, what client version or timestamp value >>> would you like jOOQ to compare the database version or timestamp value >>> with?* >>> >>> >> I didn't quite get that. >> > > If you run an update statement like you suggested, you were expecting jOOQ > to add an additional predicate for the optimistic locking check, just like > when you call record.store(). The predicate looks roughly like this: > > UPDATE layout > SET height = 15 > WHERE id = 1 > AND version = ??? > > > When you call record.store(), then the generated SQL can introspect the > record in order to place the expected version in the query (and fail if the > query doesn't update anything). > > But when you write the UPDATE statement explicitly, how could jOOQ > possibly guess what version should be the expected one? It's impossible... > > a.get(0).setHeight(15); >> a.get(0).store(); >> >> a1.get(0).setHeight(67); >> a1.get(0).store(); >> >> It throws the org.jooq.exception.DataChangedException: Database record >> has been changed exception. This is what I was looking for. >> > > Yes, exactly, that matches what I suggested. > > >> There are couple of things I can see: >> >> 1. I had a table with the following schema: >> >> create table userteams( >> userid BIGINT REFERENCES USERDATA(ID), >> teamid BIGINT REFERENCES teams(ID), >> CONSTRAINT user_teams_pk PRIMARY KEY (userid,teamid) >> ); >> >> code generation does ends up with a compilation error on keys.java file. >> I guess the code generation also creates a key called user_teams_pk, which >> already I have named it as my constraint. Looks like a bug to me. >> > > Thanks for reporting. I've created the following issue: > https://github.com/jOOQ/jOOQ/issues/6560 > > I currently cannot reproduce this, though. Would you mind providing a bit > more context? Preferably, directly on that issue on GitHub... > I guess I got confused. Now it seems to be working perfectly fine. Sorry for it! And thanks again for such a beautiful library! > > >> 2. Is there any special performance cost by making all the DSLContext to >> be withExecuteWithOptimisticLocking as true? >> > > Nothing significant. It just leads to an additional predicate being > generated on generated SQL from the aforementioned methods > > >> 3. By looking at the documentation about OL over here : >> https://www.jooq.org/doc/3.7/manual/sql-execution/crud-with >> -updatablerecords/optimistic-locking/ the code sample seems to be little >> wrong to me. Because the DSLContext's fetch does return Result<Record> not >> Record (if I'm not wrong). Guess you need to update that in the >> documentation as well. >> > > Thanks again for reporting. Will fix this immediately: > https://github.com/jOOQ/jOOQ/issues/6561 > > -- > 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/VLWO1rFJ4AM/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.
