Hi,
I would try 1). I would not try 3) because the user wouldn't know which
item conflicted (well he could parse the message, but that would be
weird). Also, I would try to avoid a new API.
For the case 'double delete' another solution is possible.
* session1 deleted node /test and does some
Hi,
On Wed, Jan 25, 2012 at 6:04 PM, Michael Dürig mdue...@apache.org 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
On Wed, Jan 25, 2012 at 6:04 PM, Michael Dürig mdue...@apache.org wrote:
Hi,
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.
Furthermore, JCR doesn't have an Item.undo() method for undoing
On 26.1.12 10:55, Jukka Zitting wrote:
Hi,
On Wed, Jan 25, 2012 at 6:04 PM, Michael Dürigmdue...@apache.org 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
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
On Thu, Jan 26, 2012 at 9:48 AM, Thomas Mueller muel...@adobe.com wrote:
Hi,
I would try 1). I would not try 3) because the user wouldn't know which
item conflicted (well he could parse the message, but that would be
weird). Also, I would try to avoid a new API.
For the case 'double delete'
BTW: the current microkernel prototype doesn't consider concurrent
removal of a specific node a conflict, i.e. it already implements the
proposed behavior.
Hmm no?
String head = mk.getHeadRevision();
head = mk.commit(/, +\qoo\:{}, head, );
String r1 = mk.commit(/, -\qoo\, head,
On Thu, Jan 26, 2012 at 2:42 PM, Michael Dürig mdue...@apache.org wrote:
BTW: the current microkernel prototype doesn't consider concurrent
removal of a specific node a conflict, i.e. it already implements the
proposed behavior.
Hmm no?
String head = mk.getHeadRevision();
head =
Hi,
but you're right, the above scenario could/should be
handled gracefully.
That makes sense. I have added a test case and changed the
MemoryKernelImpl in the sandbox.
Regards,
Thomas
Hi,
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. Furthermore, JCR doesn't have an Item.undo() method for undoing changes.
This may lead to problems when a Session.save() fails due to the
10 matches
Mail list logo
