yes, it's a design decision to only flush on commit. That's because an entity can change multiple times in a single transaction, and if you flushed earlier, then you'd have to undo the changes done so far etc (you only want max one rev entry per entity per transaction).
It would be possible to add flushing more often (for example on user demand), but that would require a code change. If you'd be willing to do a patch, please create a JIRA and attach it :)
Thanks for the response.
Yes maybe I will prepare a patch, but let me ask something:
" then you'd have to undo the changes done so far etc (you only want max one rev entry per entity per transaction). "
What if we have multiple revisions per transaction?
I see no problems with that:
- yes, maybe we have more audit-data
- but the audit is still consistent (the revisionsNumber+entityId are still unique)
Thanks & regards,
Well, 1 transaction == 1 revision, so revNumber + entityId wouldn't be unique.
I think it's best to keep the one-rev-per-transaction. Otherwise you don't know which data comes together in a revision (it's important to group the data that are changed in one TX together).
The "undoing" part is written in fact, but not very well tested.