hi michael
ok... but the subject of this thread is the behavior of nodes
upon move and as a simple test shows the behavior is the same
for both referenceable and non-referenceable nodes.
while i agree that the behavior of same nodes may change
due to the way we define the identifier, i would
On 8.2.13 9:10, Angela Schreiber wrote:
hi michael
ok... but the subject of this thread is the behavior of nodes
upon move and as a simple test shows the behavior is the same
for both referenceable and non-referenceable nodes.
while i agree that the behavior of same nodes may change
due to
sound good... the rest was probably a misunderstanding :-)
gruss
angela
On 2/8/13 10:39 AM, Michael Dürig wrote:
On 8.2.13 9:10, Angela Schreiber wrote:
hi michael
ok... but the subject of this thread is the behavior of nodes
upon move and as a simple test shows the behavior is the same
for
Sorry for jumping in without having the overall picture.
Is it really a good idea to use the path as identifier? For Referencable
Identifiers (25.1) it is pretty clear that an ID is structureindepenent, so
why should a nonreferencable be bound to a path. Since a node can return
its path I do not
in addition we still have an open TODO that the identifier
of a non-referenceable node should be as stable as possible
which means that it should include the identifier of the
parent... in other words: if one of the parent was referenceable
the identifier should be somehow combine uuid + relative
On 6.2.13 20:43, Jukka Zitting wrote:
The above rationale would imply that in Oak is to make sure that all
session refreshes and transient moves should trigger re-evaluation of
the the paths of referenceable nodes and those with a referenceable
ancestor. Other nodes should keep behaving as
as far as i remember we never decided to use the path as
identifier. we said that we want to keep it as stable as
possible... for a referenceable node Node#getIdentifier
returns the UUID for a non-referenceable node it should
include the parent identifier and a relative path thing.
kind regards
On 7.2.13 13:28, Angela Schreiber wrote:
as far as i remember we never decided to use the path as
identifier. we said that we want to keep it as stable as
possible... for a referenceable node Node#getIdentifier
returns the UUID for a non-referenceable node it should
include the parent
Hi,
On Thu, Feb 7, 2013 at 2:28 PM, Angela Schreiber anch...@adobe.com wrote:
as far as i remember we never decided to use the path as
identifier. we said that we want to keep it as stable as
possible... for a referenceable node Node#getIdentifier
returns the UUID for a non-referenceable node
On 7.2.13 13:40, Jukka Zitting wrote:
Hi,
On Thu, Feb 7, 2013 at 2:28 PM, Angela Schreiber anch...@adobe.com wrote:
as far as i remember we never decided to use the path as
identifier. we said that we want to keep it as stable as
possible... for a referenceable node Node#getIdentifier
Hi,
On 05.02.2013, at 11:47, Jukka Zitting
jukka.zitt...@gmail.commailto:jukka.zitt...@gmail.com wrote:
Do you have examples of where the new behavior would be troublesome
for existing code (not just new test cases)? The assumption from the
earlier discussion was that such cases should be
Hi,
On Wed, Feb 6, 2013 at 8:04 PM, Marcel Reutegger mreut...@adobe.com wrote:
They are easy to fix but very difficult to detect and diagnose. No exception
is thrown,
just the behavior is unexpected. I think this is quite dangerous, since the
spec is
IMO quite clear about this
hi jukka
i just learned that this discussion wasn't solely about the Tree's
behavior upon move/rename but also affects the JCR Nodes.
as stated in https://issues.apache.org/jira/browse/OAK-606
and https://issues.apache.org/jira/browse/OAK-607
the current behavior is IMO inconsistent between new
hi michael
thanks for the information. i agree that 3) currently seems the
way to go if we want to address the move issue.
from my experience move operations are rather rare (as already
noticed by jukka). in combination with the fact that our main use
case in general involves very shorted-lived
Hi,
On Tue, Feb 5, 2013 at 5:20 PM, Angela Schreiber anch...@adobe.com wrote:
as stated in https://issues.apache.org/jira/browse/OAK-606
and https://issues.apache.org/jira/browse/OAK-607
the current behavior is IMO inconsistent between new and existing
nodes and pretty strange from a JCR API
Hi,
On Tue, Feb 5, 2013 at 7:27 PM, Angela Schreiber anch...@adobe.com wrote:
from my experience move operations are rather rare (as already
noticed by jukka). in combination with the fact that our main use
case in general involves very shorted-lived sessions i would assume that
3b should be
16 matches
Mail list logo
