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 On Tuesday, 6 August 2013 03:41:12 UTC-4, Lukas Eder wrote: > >> Hi Ryan, >> >> 2013/8/2 Ryan How <[email protected]> >> >> Hi Lukas, >>> >>> That did the trick! Thanks! :) >>> >>> In the very simplistic form: >>> >>> Load in any record objects as required, these are usually bound to >>> forms, tables, etc. This can happen in multiple transactions, in several >>> stages as the user needs, etc >>> User does any changes as needed to the records (inclusing adding records >>> and deleting records) >>> On save >>> try { >>> open connection & transaction >>> storeRecordOriginalState >>> record.store() on each changed record (Or delete if deleting) >>> commit transaction >>> } catch (Optimistic Lock Exception) { >>> Special handling involving the user to resolve issues >>> } catch (Any other Exception) { >>> rollback transaction >>> restore records back to their original state >>> } finally () { >>> close connection >>> } >>> >> >> Thanks for sharing this! Makes sense to me. >> >> >>> So it is important to be able to roll back database changes and not lose >>> information in the records or the optimistic locking will not work >>> afterwards. >>> >>> It's working well now :) >>> >>> UI <-> JOOQ Records <-> Database. >>> >>> It would be fantastic if it could all happen automatically just by >>> calling .store(). That would be "magic". I don't think that should be >>> integrated into JOOQ and the architecture is very application dependent, >>> but it would be great if JOOQ could provide some hooks so I could hook into >>> .store() to do all the additional stuff. >>> >> >> I remember discussing #2010 with you. >> https://groups.google.com/**forum/#!searchin/jooq-user/** >> 2010/jooq-user/tMN1n3HCDz8/**CfavBiBWi0UJ<https://groups.google.com/forum/#!searchin/jooq-user/2010/jooq-user/tMN1n3HCDz8/CfavBiBWi0UJ> >> >> I'm currently implementing this for jOOQ 3.2: >> https://github.com/jOOQ/jOOQ/**issues/2010<https://github.com/jOOQ/jOOQ/issues/2010> >> >> This is why I'm reaching out to see what else might be needed in this new >> SPI to simplify things for people wanting to interact with jOOQ's >> optimistic locking. After all, I might not remove this feature in 4.0, if >> it can be solved properly :-) >> >> >>> Thinking about it... it is sounding a lot like hibernates flush(). Load >>> a bunch of records, do whatever changes, on calling flush() it persists it >>> to database, with any checks... But I never really liked how hibernate did >>> that :). It would be better to accumulate all the records that you want >>> only in a set, then just attach that set to a connection and .store(). I >>> guess a set <-> transaction auto populating could happen too. We also do a >>> few things like linking related records before storing them (because they >>> don't have primary keys yet), then it stores them in the correct order and >>> populates the foreign keys. >>> >> >> Interesting thoughts. Yes, I don't think that jOOQ should implement a >> Hibernate-y flush, which does things automatically (i.e. magically). Being >> able to drive the behaviour using an SPI (with 1-2 default implementations) >> seems more appropriate. >> >> >>> Anyway, I'm happy with how it is working at the moment, it isn't worth >>> the extra effort for me to try and support this flexibility unless I start >>> another project and want to get it in from the start. JOOQ does a great job >>> of what it does. It seems like it would be expanding the scope of jooq to >>> start getting into this other stuff, could almost be a separate project. >>> >> >> Yes it would be a separate project. >> >> 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/groups/opt_out. > > > -- 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.
