On 26.1.12 10:55, Jukka Zitting wrote:
Hi,
On Wed, Jan 25, 2012 at 6:04 PM, Michael Dürig<[email protected]> wrote:
In an earlier discussion (probably offline), we decided to not implement
Item.refresh() since it doesn't go well with the MVCC model jr3 is based on.
I'd implement Item.refresh() like this:
public void refresh(boolean keepChanges) throws RepositoryException {
if (!keepChanges) {
discardTransientChangesBelowThisItem();
}
// Update the MVCC base state of this session to the latest
// state of the workspace.
getSession().refresh(true);
}
In other words, Item.refresh() would always trigger a refresh() of the
entire session. That's OK spec-wise, since it's always OK for the
implementation to refresh the session state at any point of time it
wants.
That's an interesting approach. Will think about it. I think this
together with 1) will could be a viable solution.
Michael
Furthermore, JCR doesn't have an Item.undo() method for undoing changes.
I'd treat refresh(false) as undo(), both on Item and Session level.
This may lead to problems when a Session.save() fails due to the underlying
Microkernel.commit failing because it detected a conflict. Now there might
be some transient changes (like deletions) which can't be selectively undone
by the user. So the user is left with a transient space containing his
changes but he can only discard them as a whole. Not very satisfactory.
I think that's fine, especially if we implement Item.refresh(false)
with an internal discardTransientChangesBelowThisItem() operation as
described above.
1) The Microkernel makes as much effort as possible to three way merge
changes.
I think we should do this in any case.
2) The user needs to do a session refresh with keep changes = true and save
again.
I'd always automatically trigger a refresh(true) at the beginning of a
save() call.
3) Introduce a Item.undo method on the JCR API.
As mentioned above, I think Item.refresh(false) could already cover
the required functionality.
BR,
Jukka Zitting
