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.
> 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
