Hi Lukas,
I was just thinking about this (I haven't tried it yet from git). What
do you think about the case where multiple records are stored, but an
error occurs part way so the transaction is rolled back. This will mean
that the objects are out of sync with the database (Some will have
updated "original" data, others will not). The only way of getting them
back in sync is to do a "refresh" which will effectively clear out any
uncommitted data. In this case the old behaviour would be preferable,
then after the transaction is successfully committed the records
"original" data can be manually triggered to be set to the records
current data.
Any thoughts?
Perhaps if using batchStore then they can all be stored and then updated
afterwards as a single unit?
I guess there is no way to automatically handle this as JOOQ can't be
sure when the underlying transaction is actually committed? I'm not sure
how this situation is normally handled with optimistic locking and
transactions.
Thanks, Ryan
On 10/12/2012 5:36 AM, Lukas Eder wrote:
You're probably right. "original" values should be updated, once a
record is stored successfully. I'll check to see if I can reproduce
this. I have registered #1995 for this:
https://github.com/jOOQ/jOOQ/issues/1995
I can confirm this issue. Other use-cases are affected, too - e.g.
- batch storing
- Record.into(Table)
This is fixed on GitHub master and will be merged downstream to the
upcoming 2.6.1 patch release
Cheers
Lukas
