Re: DM Rule #4: Beware of Same Name Siblings.

[Peter Dotchev <do...@gmail.com>]

Hi,

After reading this whole discussion, I'm still not convinced that SNS are
bad.

If they are inefficient, that is an implementation issue that should be
addressed in the proper place.

As seen in this discussion even if you want you can't come with really
meaningful paths due to name conflicts and changes over time.
Actually if you want to avoid SNS you have to come up with (locally but
still) unique names.
- These are essentially id's which contradicts rule #7
- It gets more complicated as you have to implement some algorithm to
generate unique names and most probably you have to deal with concurrency
issues. Is it really necessary?

I would not consider path stable, so I use UUID in URLs.

While meaningful paths would be nice I don't think they are so important. I
think in most cases users are not interacting directly with the repository
but with some (web) application which uses the repository as storage
back-end.

Generally I think the concept here is pretty simple.
I have a collection with a bunch of entities. I don't need and don't want to
name them. Each entity has some properties. I just want to add, remove,
query and edit them.
There should be a straightforward way to achieve this.

Best regards,
Peter

-- 
View this message in context: http://n4.nabble.com/DM-Rule-4-Beware-of-Same-Name-Siblings-tp514376p1474048.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

Re: DM Rule #4: Beware of Same Name Siblings.

[Alexander Klimetschek <ak...@day.com>]

On Tue, Feb 9, 2010 at 09:41, Thomas Müller <th...@day.com> wrote:
>> I'm still not convinced that SNS are bad.
>>
>> If they are inefficient, that is an implementation issue that should be
>> addressed in the proper place.
>
> That's complicated. SNS means a node name index could change (because
> a sibling was added or removed). If you have many SNS then removing
> the first one will change the index of all others. This is like
> removing the first element of a large array.

To further underline that: the problem is that the path to a node,
that you might store as a reference somewhere else, could change
"silently" without that node being touched at all. Just because a
sibling was added or removed.

For example: /documents/current/image[2] could become
/documents/current/image[3] if some other image was added as sibling
before. This effectively disables the use of paths as simple and exact
identifiers for that node and you are either required to use UUIDs
(has drawbacks itself, see rule #5 and #7) or some other custom
mechanism (even more worse).

So this is a conceptual problem of SNS in JCR, independent of any
implementation, and is what makes them generally "bad".

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: DM Rule #4: Beware of Same Name Siblings.

[Thomas Müller <th...@day.com>]

Hi,

> I'm still not convinced that SNS are bad.
>
> If they are inefficient, that is an implementation issue that should be
> addressed in the proper place.

That's complicated. SNS means a node name index could change (because
a sibling was added or removed). If you have many SNS then removing
the first one will change the index of all others. This is like
removing the first element of a large array.

> Actually if you want to avoid SNS you have to come up with (locally but
> still) unique names.

That's a good idea.

> - These are essentially id's which contradicts rule #7

I don't think that IDs are that evil, but if you want something that
is 'human readable' you could use timestamps.

> - It gets more complicated as you have to implement some algorithm to
> generate unique names and most probably you have to deal with concurrency
> issues. Is it really necessary?

I guess we should have a utility method that generates nodes with
guaranteed unique ids or timestamps (that could be part of JCR
Commons).

> I would not consider path stable, so I use UUID in URLs.

Sometimes using UUIDs is necessary (for example if you want to merge
multiple repositories at some point). Otherwise locally unique IDs
(within the same repository) should be sufficient.

Regards,
Thomas