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
I'm currently implementing this for jOOQ 3.2:
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.
