2013/8/8 Ryan How <[email protected]> > On 7/08/2013 3:24 PM, Lukas Eder wrote: > > Hello, > > 2013/8/6 Venkat Sadasivam <[email protected]> > >> Ryan - You have discovered a nice problem to be resolved. I cache Record >> object at web layer to re-use them across multiple http request, if my >> transaction is rolled back then my cache object at web layer becomes >> incorrect also its too hard to track and rollback every record updated in >> the failed transaction. >> >> Lukas - from a framework perspective it would be nice to add rollback() >> method in UpdatableRecord to bring it back to original state then its upto >> the transaction layer to call the rollback() method. >> > > The problem here is to know what the "original" state really is. > > jOOQ already maintains an "original" state through Record.original(). > This state corresponds to what was originally loaded from the database. > Upon successful store, this "original" state is set to the Record's value. > > While I agree that this behaviour is cumbersome when rolling back a > transaction, I'm not sure if there's an easy solution to this, which suits > all use-cases and transaction models. > > The silliest solution to this problem might be to add an > UpdatableRecord.refreshOriginal() method, to re-read original values from > the database, without affecting the other values. Would that make sense? > > Cheers > Lukas > > > For that to work wouldn't it need to know the original original values?, > or at least the original original primary key value, otherwise after it is > stored, the original state will be updated, so refreshing it may not be > accurate. >
I haven't thought this through. It may as well be that refreshOriginal() would just add yet another layer of 90%-completeness to this implementation. Thus, the "silliest solution". But jOOQ's CRUD Javadoc already has a couple of references to it assuming a certain level of relational normalisation. I.e. updating primary key values in a record is not recommended. But the question remains: how would such a "refreshOriginal()" method behave once a transaction is committed? Will that "original original" need to be adapted then? Sigh... It would almost seem to work with all cases it would need record > "versioning". Then it could handle savepoints too and roll back to an > arbitrary point. Then it is just up to the end implementation to hook in > the records with the transaction layer to keep it all in sync. > > I think with "versioning", those listeners you are working on, and record > "sets" to "track" all your records, you could implement just about any use > case you needed to. It is just up to the end implementation to hook it all > together in a way that makes sense for them (eg. hooking up a "set" to a > transaction so they can be committed and rolled back as a single unit). > Yes. In the long run, I'd favour such a solution, myself. What I like about this, in particular, is the fact that an SPI exists for users to implement their own versioning, which is well-aligned to their transaction model (including savepoints, as you've mentioned). Eventually, we'll get there, I think! :-) -- 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/groups/opt_out.
