You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by David Nuescheler <da...@gmail.com> on 2007/07/07 13:16:47 UTC
DM Rule #4: Beware of Same Name Siblings.
Explanation
---
While Same Name Siblings (SNS) have been introduced into the spec to
allow compatibility with data structures that are designed for and
expressed through XML and therefore are extremely valuable to JCR, SNS
come with a substantial overhead and complexity for the repository.
Any path into the content repository that contains an SNS in one of
its path segments becomes much less stable, if an SNS is removed or
reordered, it has an impact on the paths of all the other SNS and
their children.
For import of XML or interaction with existing XML SNS maybe necessary
and useful but I have never used SNS, and never will in my "green
field" data models.
Example:
---
Use
/content/myblog/posts/what_i_learned_today
/content/myblog/posts/iphone_shipping
instead of
/content/blog[1]/post[1]
/content/blog[1]/post[2]
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 7/10/07, sbarriba <sb...@yahoo.co.uk> wrote:
> So can we conclude this thread with a JCR pattern/best practise for
> modelling the following?
>
> * ordered composition examples e.g. an ordered list
>
> * unordered composition example e.g. a bag
I think ordering is orthogonal to naming.
You can set the ordered bit on a node type to determine whether the
list of child nodes is ordered or not, but personally I don't think it
makes that much difference and tend to default to using ordered nodes
that cover both cases.
The bag data structure (name-value map that can have multiple distinct
values per name) is a typical candidate for using same name siblings,
but an equally valid alternative would be to use a collection subnode
with some second level of naming for things that fall under the same
name in the bag structure.
BR,
Jukka Zitting
RE: DM Rule #4: Beware of Same Name Siblings.
Posted by sbarriba <sb...@yahoo.co.uk>.
Hi David et al,
(...definite opportunity for a book here David :))
"People use SNS mostly for large, unordered collections, which it is
definitely not what they are designed for."
When mapping our object model to JCR I used SNS for almost all composition
relationships, both ordered and unordered. Mainly as I assumed this was the
intended way to model anonymous composition. It never quite felt right for
the ordered case as you have to then make the parent object 'ordered' which
seemed wrong as then all multi-node properties are 'ordered'.....so this
thread is proving an eye opener.
I tried to think of an abstract example in the car/seat use-case but the
group still managed to find appropriate 'names' for the nodes :) If I think
hard enough I can come up with semi-useful node names for most of the
relationships in our model.
So can we conclude this thread with a JCR pattern/best practise for
modelling the following?
* ordered composition examples e.g. an ordered list
* unordered composition example e.g. a bag
Regards,
Shaun.
-----Original Message-----
From: David Nuescheler [mailto:david.nuescheler@gmail.com]
Sent: 09 July 2007 13:28
To: users@jackrabbit.apache.org
Subject: Re: DM Rule #4: Beware of Same Name Siblings.
Hi Shaun,
thanks for your feedback.
> Our model includes various SNS and while 'yes' I agree that [1],[2] etc
> aspect can cause problems how else would you model anonymous composition
> where Object A contains multiple instances of Object B, where Object B has
> no unique & distinguishing concept of a name.
> For example,
> [acme:Car]
> acme:seats multiple acme:Seat
> What would be your preferred way to model the above in a green field
model?
I agree with Felix on using a subnode.
If I read Felix's recommendation we would end up with
something like:
/mercedes/s-class/s-500/seats/0
/mercedes/s-class/s-500/seats/1
/mercedes/s-class/s-500/seats/2
Based on the idea that arbitrary numbers hardly ever
qualify as a "good name", I would probably go further
in leveraging my hierarchy and use something like:
/mercedes/s-class/s-500/seats/driver
/mercedes/s-class/s-500/seats/passenger
/mercedes/s-class/s-500/seats/back-left
I think this adds context for people navigating
the hierarchy. Even for people searching the
content repository and for whatever reason finding a
"seat", they will automatically know that they are looking
at a drivers seat of an s-500 mercedes without any
further information beyond the path.
In my mind this context information is a valuable asset
and therefore should not be given away lightly.
It may well be that I misunderstood the "seat" example,
so please let me know if this all makes sense.
regards,
david
> -----Original Message-----
> From: David Nuescheler [mailto:david.nuescheler@gmail.com]
> Sent: 07 July 2007 12:17
> To: users@jackrabbit.apache.org
> Subject: DM Rule #4: Beware of Same Name Siblings.
>
> Explanation
> ---
> While Same Name Siblings (SNS) have been introduced into the spec to
> allow compatibility with data structures that are designed for and
> expressed through XML and therefore are extremely valuable to JCR, SNS
> come with a substantial overhead and complexity for the repository.
>
> Any path into the content repository that contains an SNS in one of
> its path segments becomes much less stable, if an SNS is removed or
> reordered, it has an impact on the paths of all the other SNS and
> their children.
>
> For import of XML or interaction with existing XML SNS maybe necessary
> and useful but I have never used SNS, and never will in my "green
> field" data models.
>
> Example:
> ---
> Use
>
> /content/myblog/posts/what_i_learned_today
> /content/myblog/posts/iphone_shipping
>
> instead of
>
> /content/blog[1]/post[1]
> /content/blog[1]/post[2]
>
>
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Thomas Mueller <th...@gmail.com>.
> ../contacts/mark@gmail/ituneslibrary/Nelly Furtado/Loose/Say It Right...
Part of this path is an 'application identifier': ../contacts/../ituneslibrary/
Usually, 'application identifiers' are stable and change only when the
application changes (sometimes 'refactoring tools' can help).
'Unstable user data': email addresses, names, places, phone numbers,
social security numbers, sex, fingerprint, whatever. All this is
unstable:
/mark@gmail
Nelly Furtado/Loose/Say It Right...
Then there are 'stable data identifiers': unique identifiers
(counters, timestamps, UUIDs).
As a developer, I like to avoid writing extra code to 'refactor
unstable user data'. Specially if the unstable user data is used in
multiple places, as in:
/contacts/mark@gmail/
/contacts/mark@gmail/email=mark@gmail
...
/comments/mark@gmail/
...
The email address can change, so I need to write code to change it in
all places (including references). However if I use stable unique
identifiers, there is no problem. This is the reason to use 'article
id', 'person id', 'order id' and so on: Because developers are lazy.
Personally, I would rather use stable identifiers (for example
counters) than keep 'wrong' email addresses, or risk typos in blog
URLs. But this is just my view.
Thomas
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Thomas Mueller <th...@gmail.com>.
> I think people are placing all too much emphasis on the semantic
> meaning of the path.
I thought I had a cool idea, and now it's wrong? Why?
> As mentioned above, IMHO the meaningfullness
> should be about grouping, local identification, and human readability,
If the data is old and all wrong, it is not meaningful at all in (my view).
> *not* about specific properties of the node.
> There is obviously a
> relation between these things, but I really wouldn't stress that too
> much.
And why not?
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by 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.
Posted by 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
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by 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.
Posted by Tako Schotanus <qu...@gmail.com>.
On 7/10/07, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
snip
>
> It's really a balancing act between the stability of the paths and how
> much you can imply from the fact that a node resides for example
> within /basel/barfuesserplatz-6. My node might well be placed in that
> tree (for non-Day people, I work remotely as a part of the Day R&D
> team who's mainly based in Basel) for organizational reasons even
> though my actual address would place me in /espoo/paivankajontie-4.
True, but there is nothing inherently incorrect with that information.
>From the point of view of the organization you're part of the basel
office while your actual location is somewhere else. Both of these
fact might be somehow incorporated in the nodes, properties or the
naming of the hierarchy. But it's another thing to have stale
information in the repository.
For me it's simple, you either use meaningful path names because
humans will actually use them or people will always point and click
and in that case you could have whatever name you want. I recognize
that there might be applications where it doesn't matter if the
"meaningful path" is stale, but I guess that in lots if not most
applications this would be a big nuisance.
In the end it all depends on your application and after reading this
thread it's obvious that there is no one system that is best for all
situations. So if this is to turn into an article for the wiki I think
it would be best to give some examples for each of the use-cases and
explain the pros and cons of each one (explaining the big downside of
SNS is most important though IMHO).
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 7/10/07, David Nuescheler <da...@gmail.com> wrote:
> > I think people are placing all too much emphasis on the semantic
> > meaning of the path.
> I believe that's up to the application to decide.
Sure. My point is that treating individual path elements as properties
of the target node (as might be implied from
country/city/lastname/firstname, etc.) is bad practice. The node
itself should IMHO contain all relevant information even if it's named
"/foo[2385]".
Using some properties as the basis of selecting a node name and
deciding where the node should be placed is an excellent idea, but I'm
not so sure if it makes sense to enforce that these properties will
always be used as the path of the node.
It's really a balancing act between the stability of the paths and how
much you can imply from the fact that a node resides for example
within /basel/barfuesserplatz-6. My node might well be placed in that
tree (for non-Day people, I work remotely as a part of the Day R&D
team who's mainly based in Basel) for organizational reasons even
though my actual address would place me in /espoo/paivankajontie-4.
BR,
Jukka Zitting
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by David Nuescheler <da...@gmail.com>.
Hi Jukka,
> I think people are placing all too much emphasis on the semantic
> meaning of the path.
I believe that's up to the application to decide.
Moving my document from the "/very-secret" folder into the "/public" folder
may certainly bear some relevance from an inherited access control
perspective.
So some applications may choose stable paths (the blog
example for the URL's sake) other apps may have a greater focus
on a "meaningful and correct" paths like for example a phone book
application. see below:
http://tel.search.ch/basel/barfuesserplatz-6/day-interactive-switzerland-ag.en.html
http://tel.search.ch/basel/barfuesserplatz-6/*.en.html
http://tel.search.ch/basel/*.en.html
I think there is no right or wrong. The good news is that JCR equips you
with all the means to satisfy both needs.
regards,
david
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 7/10/07, Thomas Mueller <th...@gmail.com> wrote:
> > The path /people/spain/barcelona/JuanJoseRodrigueszMorales is still a
> > lot more "meaningful" than /people/894758. The "meaningfulness" is
> > about grouping, local identification, and human readability.
>
> I agree! I think I found a way to be lazy, and have meaningful and
> up-to-date paths:
-1
I think people are placing all too much emphasis on the semantic
meaning of the path. As mentioned above, IMHO the meaningfullness
should be about grouping, local identification, and human readability,
*not* about specific properties of the node. There is obviously a
relation between these things, but I really wouldn't stress that too
much.
BR,
Jukka Zitting
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Thomas Mueller <th...@gmail.com>.
> The path /people/spain/barcelona/JuanJoseRodrigueszMorales is still a
> lot more "meaningful" than /people/894758. The "meaningfulness" is
> about grouping, local identification, and human readability.
I agree! I think I found a way to be lazy, and have meaningful and
up-to-date paths:
AutoPathTool tool = new AutoPathTool(session);
tool.setRootPath("/people");
tool.setPathMapping("{@country}/{@city}/{@lastName}/{@firstName}-{counter}");
tool.setFilter("nt:unstructured");
tool.start();
This tool would install an observation listener, and automatically
remap all nodes based on the properties (and changes to properties).
OK, you don't have a stable path (but how can you?).
Thomas
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 7/10/07, Jukka Zitting <ju...@gmail.com> wrote:
> ...The path /people/spain/barcelona/JuanJoseRodrigueszMorales is still a
> lot more "meaningful" than /people/894758. The "meaningfulness" is
> about grouping, local identification, and human readability....
Listening to the recent discussions, what might help as a general rule
is to include the time dimension in such paths:
/people/2007-06/spain/barcelona/JuanJoseRodrigueszMorales
This will always stay true, if Juan lived in Barcelona in 2007-06,
when that node was created.
-Bertrand
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 7/10/07, Tako Schotanus <qu...@gmail.com> wrote:
> I person that was put in /people/spain/madrid/JuanJoseRodriguezMorales
> who moves to Barcelona should be moved to /people/spain/barcelona in
> my opinion. Leaving him in madrid just defeats the whole purpose of
> having meaningful names IMHO.
The path /people/spain/barcelona/JuanJoseRodrigueszMorales is still a
lot more "meaningful" than /people/894758. The "meaningfulness" is
about grouping, local identification, and human readability.
If you really do need to refer to this specific person regardless of
where he lives or what his name is (the name can also change), then
you will want to use something like a social security number or a UUID
if another global identifier is not available.
BR,
Jukka Zitting
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Tako Schotanus <qu...@gmail.com>.
Sorry, but I can't live with that :-)
Blog titles won't change that often (if they do maybe you should think
about them a bit more) but in lots of other cases information like
that might change a lot and would soon fill the repository with
rubbish. I thought the rule was to have meaningful names? :-)
I person that was put in /people/spain/madrid/JuanJoseRodriguezMorales
who moves to Barcelona should be moved to /people/spain/barcelona in
my opinion. Leaving him in madrid just defeats the whole purpose of
having meaningful names IMHO.
On 7/10/07, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On 7/10/07, Bertrand Delacretaz <bd...@apache.org> wrote:
> > IIUC this means that "/mark@gmail/stuff" would stay as is, even if
> > mark changes his email later on - in fact this is the exact same
> > problem as a blog post stored under 2007/some_title, where the title
> > changes later but the path shouldn't.
>
> Exactly.
>
> BR,
>
> Jukka Zitting
>
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 7/10/07, Bertrand Delacretaz <bd...@apache.org> wrote:
> IIUC this means that "/mark@gmail/stuff" would stay as is, even if
> mark changes his email later on - in fact this is the exact same
> problem as a blog post stored under 2007/some_title, where the title
> changes later but the path shouldn't.
Exactly.
BR,
Jukka Zitting
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 7/10/07, Jukka Zitting <ju...@gmail.com> wrote:
> ....I guess we need to make a difference between meaningful paths in the
> sense of "locally unique and readable" and the sense of "semantically
> valid" where someone would want to use the name itself as a specific
> attribute like name or email address. I much prefer treating names in
> the former sense....
Ok, I see your point, thanks for clarifying!
IIUC this means that "/mark@gmail/stuff" would stay as is, even if
mark changes his email later on - in fact this is the exact same
problem as a blog post stored under 2007/some_title, where the title
changes later but the path shouldn't.
-Bertrand
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 7/10/07, Bertrand Delacretaz <bd...@apache.org> wrote:
> Still (and I'm being slightly paranoid here, for the purpose of
> discussion), some of these meaningful path elements might change at
> some point.
I don't really see this as a problem.
> mark@gmail might get a new email...what happens? Worst case, his old
> email is made available after some time, and someone else grabs it
> (remember, I'm in paranoid mode ;-)
We can just rename the node, or if we don't care we can leave it as
is. In any case I think it makes sense *not* to use the node name as
the email address in an aplication. It's much better to put such
semantic information in a property and keep the name as just a local
identifier.
> "Nelly Furtado" usually stays forever...though she might get married
> and change her name (not to mention the Wendy/Walter Carlos case
> [1]...or The Artist Formerly Known As Prince).
>
> New records will be released under her new name, but somehow a
> connection must be made to the old name, which would be easier with an
> abstract identifier.
Again, in this model each record should probably have a string
property that contains the name of the artist.
> What I'm getting at: meaningful paths are great, but when using them
> one must be prepared to handle edge cases where meaningful path
> elements change in the world that you're modeling.
I guess we need to make a difference between meaningful paths in the
sense of "locally unique and readable" and the sense of "semantically
valid" where someone would want to use the name itself as a specific
attribute like name or email address. I much prefer treating names in
the former sense.
BR,
Jukka Zitting
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 7/10/07, David Nuescheler <da...@gmail.com> wrote:
> .../contacts/mark@gmail/ituneslibrary/Nelly Furtado/Loose/Say It Right...
> ..and really, i cannot see a drawback for naming
> nodes in a meaningful way. ;)...
Still (and I'm being slightly paranoid here, for the purpose of
discussion), some of these meaningful path elements might change at
some point.
mark@gmail might get a new email...what happens? Worst case, his old
email is made available after some time, and someone else grabs it
(remember, I'm in paranoid mode ;-)
"Nelly Furtado" usually stays forever...though she might get married
and change her name (not to mention the Wendy/Walter Carlos case
[1]...or The Artist Formerly Known As Prince).
New records will be released under her new name, but somehow a
connection must be made to the old name, which would be easier with an
abstract identifier.
What I'm getting at: meaningful paths are great, but when using them
one must be prepared to handle edge cases where meaningful path
elements change in the world that you're modeling.
-Bertrand
[1] http://en.wikipedia.org/wiki/Wendy_Carlos
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 7/10/07, Tako Schotanus <qu...@gmail.com> wrote:
> On 7/10/07, Jukka Zitting <ju...@gmail.com> wrote:
> > Note that names don't really need to be globally unique or stable. A
> > name doesn't even need to reflect any specific attribute (real name,
> > etc.) of the node.
>
> I understand, they only need to be unique to their parent, but they
> don't need to be stable? Then how are you going to reference them if,
> like rule #5 says "references are considered harmful"? If you keep
> changing them you need to keep updating all your references?
Having stable names is useful but it's not something that you need to
enforce absolutely. If it makes sense for your application to rename a
node and you can update all path references or live with broken links,
then I see no reason not to change things.
In fact I typically try to model my applications in a way that allows
me to do major restructurings if I want. For example I might start
with a date-based hierarchy for a blog engine, but later on decide to
use topic-based classification. I might even want to have two such
hierarchies in parallel within the same application and allow myself
to move entries around at will.
> > A geographic hierarchy would divide people based on the area, city,
> > street, block, etc. where they live in.
>
> People move all the time.
>
> But maybe I see this stability thing as something more important than
> it really is, you I'll wait what your response to the above is :-)
I'll follow up on the reference thread on my thinking on hard
references. As for path stability, I think it's harmful if you start
treating paths as *hard* references that can't change.
BR,
Jukka Zitting
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Tako Schotanus <qu...@gmail.com>.
On 7/10/07, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On 7/10/07, Tako Schotanus <qu...@gmail.com> wrote:
> > I understand the recommendation, I just would like to add that
> > sometimes finding a good identifier is pretty difficult. The example
> > of using a person's email address is just not stable enough, there are
> > lots of people who are changing email addresses continuously and many
> > of the addresses don't contain any clue as to the person they belong
> > to.
>
> Note that names don't really need to be globally unique or stable. A
> name doesn't even need to reflect any specific attribute (real name,
> etc.) of the node.
I understand, they only need to be unique to their parent, but they
don't need to be stable? Then how are you going to reference them if,
like rule #5 says "references are considered harmful"? If you keep
changing them you need to keep updating all your references?
>
> > And since the 1.5 years that I live in Spain now I'm still amazed at
> > the number of people that have EXACTLY the same name! Even taking into
> > account that they have 2 last names (from both parents) and normally
> > several first names as well! (Probably due to the fact that it was
> > customary to name children after grandparents)
>
> This is where the recommendation to avoid huge flat collections comes
> to help. A repository that models the population of Spain could (and
> should!) use some hierarchy.
>
> A geographic hierarchy would divide people based on the area, city,
> street, block, etc. where they live in.
People move all the time.
But maybe I see this stability thing as something more important than
it really is, you I'll wait what your response to the above is :-)
Cheers,
-Tako
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 7/10/07, Tako Schotanus <qu...@gmail.com> wrote:
> I understand the recommendation, I just would like to add that
> sometimes finding a good identifier is pretty difficult. The example
> of using a person's email address is just not stable enough, there are
> lots of people who are changing email addresses continuously and many
> of the addresses don't contain any clue as to the person they belong
> to.
Note that names don't really need to be globally unique or stable. A
name doesn't even need to reflect any specific attribute (real name,
etc.) of the node.
> And since the 1.5 years that I live in Spain now I'm still amazed at
> the number of people that have EXACTLY the same name! Even taking into
> account that they have 2 last names (from both parents) and normally
> several first names as well! (Probably due to the fact that it was
> customary to name children after grandparents)
This is where the recommendation to avoid huge flat collections comes
to help. A repository that models the population of Spain could (and
should!) use some hierarchy.
A geographic hierarchy would divide people based on the area, city,
street, block, etc. where they live in.
A geneologic hierarchy could use either maternal or paternal lines and
have the repository hierarchy reflect the actual parent/child
relations in real world.
BR,
Jukka Zitting
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Tako Schotanus <qu...@gmail.com>.
I understand the recommendation, I just would like to add that
sometimes finding a good identifier is pretty difficult. The example
of using a person's email address is just not stable enough, there are
lots of people who are changing email addresses continuously and many
of the addresses don't contain any clue as to the person they belong
to.
And since the 1.5 years that I live in Spain now I'm still amazed at
the number of people that have EXACTLY the same name! Even taking into
account that they have 2 last names (from both parents) and normally
several first names as well! (Probably due to the fact that it was
customary to name children after grandparents)
Of course it would still be possible to use names and some algorithm
to ensure uniqueness in some way and I understand that from the
perspective of path name stability this is preferred.
On 7/10/07, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On 7/10/07, David Nuescheler <da...@gmail.com> wrote:
> > ..and really, i cannot see a drawback for naming
> > nodes in a meaningful way. ;)
>
> There is always an inherent cost in naming things especially in design
> time, but as discussed the benefit of naming really outweights this
> cost in most, if not all, cases. So, very much agreed.
>
> In fact I would rather phrase the rule as a pattern like "Use locally
> unique names" instead of using an antipattern. Also, the emphasis on
> proper naming nicely resonates with the recommendation to avoid
> identifiers.
>
> BR,
>
> Jukka Zitting
>
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 7/10/07, David Nuescheler <da...@gmail.com> wrote:
> ..and really, i cannot see a drawback for naming
> nodes in a meaningful way. ;)
There is always an inherent cost in naming things especially in design
time, but as discussed the benefit of naming really outweights this
cost in most, if not all, cases. So, very much agreed.
In fact I would rather phrase the rule as a pattern like "Use locally
unique names" instead of using an antipattern. Also, the emphasis on
proper naming nicely resonates with the recommendation to avoid
identifiers.
BR,
Jukka Zitting
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by David Nuescheler <da...@gmail.com>.
Hi Mark,
Thanks a lot for your comment.
> /contacts/johndoe
> /contacts/janedoe
> etc.
> Maybe just using
> /contact/contact[1]
> /contact/contact[2]
> and using uuid's to reference individuals make sense for this?
I think it is important to look at (a) a meaningful path that is
explanatory of the context that you are in and (b) stable and unique
identification as two totally separate issues.
(a) Meaningful Path
------
[which really belongs into the "drive your hierarchy" section]
I mainly use SNS as a symptom to diagnose a hierarchy issue
in a content model.
People use SNS mostly for large, unordered collections,
which it is definitely not what they are designed for.
[note to self: propose a better way to address this problem in jsr-283]
SNS means that if you for example remove contact[1] the
paths of all other contacts and all their children will need to
change.
Keep in mind that you force the repository to keep track of the
order of your contacts. Which you are actually not interested in
I would assume.
While I think that...
/contacts/0
/contacts/1
/contacts/2
/contacts/3
... is better from that perspective, since the repository does not
need to keep track of sort order and you get better path stability,
I would still try something like...
/contacts/david@day.com
/contacts/dev@jackrabbit.apache.org
...which could be both meaningful and unique.
The reason for that is that someone who browses the repository
with any form of generic application ...
(like http://jsr170tools.day.com/crx/browser/index.jsp)
... understands get a meaningful list of contacts and
the path reveals information about the context of the
information.
Let's assume the path should ever surface, for example in a URL,
then...
/contacts/mark@gmail/ituneslibrary/Nelly Furtado/Loose/Say It Right
will give the user much more context than ...
/contacts/contact[42342]/ituneslib/artist[234]/album[2]/track[8]
..and really, i cannot see a drawback for naming
nodes in a meaningful way. ;)
---------
(b) Stable and Unique Identification
----
If your contacts should be mix:referenceable and therefore expose
a UUID so they can be referenced in my mind is decided by
the needs of you application.
If you application needs to reference users in a stable fashion and
you don't have something like a unique stable user-id (eg. an email
or a login...) mix:referenceable certainly would be the way to go.
(Important: this does not mean that a hard reference property
needs to be used to refer to or identify the node later)
-----
Please keep in mind, this is just how I would model the content,
and I am convinced that someone could possibly come up with
a usecase where even I would warm up to the idea of using SNS... ;)
regards,
david
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Mark,
You are absolutely right, that naming collisions tend to be an issue.
But instead of falling back to using SNS - or can you tell something
about contact[2] ? - I would rather add some conflict resolution
algorithm such as adding the initial or middle name. Alternatively you
might want to use the user ID as the node name or the email address,
which should be unique.
Regards
Felix
Am Montag, den 09.07.2007, 16:16 -0400 schrieb Mark Waschkowski:
> What would be the prescribed method when saving people? Seems a bit odd to
> try and shoehorn people's names into node names, dealing with naming
> collisions etc.
>
> ie.
> /contacts/johndoe
> /contacts/janedoe
> etc.
>
> Maybe just using
>
> /contact/contact[1]
> /contact/contact[2]
>
> and using uuid's to reference individuals make sense for this?
>
> Regards,
>
> Mark
>
> On 7/9/07, Raphael Wegmueller <ra...@gmail.com> wrote:
> >
> > maybe shaun's example is more about seat types rather than locations... ;)
> >
> > /audi/a8/w12/seats/sports
> > /audi/a8/w12/seats/comfort
> > /audi/a8/w12/seats/standard
> >
> > either way, the point is that node names should as meaningful as
> > possible in their given context (parent).
> >
> > On 7/9/07, David Nuescheler <da...@gmail.com> wrote:
> > > Hi Shaun,
> > >
> > > thanks for your feedback.
> > >
> > > > Our model includes various SNS and while 'yes' I agree that [1],[2]
> > etc
> > > > aspect can cause problems how else would you model anonymous
> > composition
> > > > where Object A contains multiple instances of Object B, where Object B
> > has
> > > > no unique & distinguishing concept of a name.
> > > > For example,
> > > > [acme:Car]
> > > > acme:seats multiple acme:Seat
> > > > What would be your preferred way to model the above in a green field
> > model?
> > >
> > > I agree with Felix on using a subnode.
> > >
> > > If I read Felix's recommendation we would end up with
> > > something like:
> > >
> > > /mercedes/s-class/s-500/seats/0
> > > /mercedes/s-class/s-500/seats/1
> > > /mercedes/s-class/s-500/seats/2
> > >
> > > Based on the idea that arbitrary numbers hardly ever
> > > qualify as a "good name", I would probably go further
> > > in leveraging my hierarchy and use something like:
> > >
> > > /mercedes/s-class/s-500/seats/driver
> > > /mercedes/s-class/s-500/seats/passenger
> > > /mercedes/s-class/s-500/seats/back-left
> > >
> > > I think this adds context for people navigating
> > > the hierarchy. Even for people searching the
> > > content repository and for whatever reason finding a
> > > "seat", they will automatically know that they are looking
> > > at a drivers seat of an s-500 mercedes without any
> > > further information beyond the path.
> > >
> > > In my mind this context information is a valuable asset
> > > and therefore should not be given away lightly.
> > >
> > > It may well be that I misunderstood the "seat" example,
> > > so please let me know if this all makes sense.
> > >
> > > regards,
> > > david
> > >
> > > > -----Original Message-----
> > > > From: David Nuescheler [mailto:david.nuescheler@gmail.com]
> > > > Sent: 07 July 2007 12:17
> > > > To: users@jackrabbit.apache.org
> > > > Subject: DM Rule #4: Beware of Same Name Siblings.
> > > >
> > > > Explanation
> > > > ---
> > > > While Same Name Siblings (SNS) have been introduced into the spec to
> > > > allow compatibility with data structures that are designed for and
> > > > expressed through XML and therefore are extremely valuable to JCR, SNS
> > > > come with a substantial overhead and complexity for the repository.
> > > >
> > > > Any path into the content repository that contains an SNS in one of
> > > > its path segments becomes much less stable, if an SNS is removed or
> > > > reordered, it has an impact on the paths of all the other SNS and
> > > > their children.
> > > >
> > > > For import of XML or interaction with existing XML SNS maybe necessary
> > > > and useful but I have never used SNS, and never will in my "green
> > > > field" data models.
> > > >
> > > > Example:
> > > > ---
> > > > Use
> > > >
> > > > /content/myblog/posts/what_i_learned_today
> > > > /content/myblog/posts/iphone_shipping
> > > >
> > > > instead of
> > > >
> > > > /content/blog[1]/post[1]
> > > > /content/blog[1]/post[2]
> > > >
> > > >
> > >
> >
>
>
>
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Mark Waschkowski <mw...@gmail.com>.
What would be the prescribed method when saving people? Seems a bit odd to
try and shoehorn people's names into node names, dealing with naming
collisions etc.
ie.
/contacts/johndoe
/contacts/janedoe
etc.
Maybe just using
/contact/contact[1]
/contact/contact[2]
and using uuid's to reference individuals make sense for this?
Regards,
Mark
On 7/9/07, Raphael Wegmueller <ra...@gmail.com> wrote:
>
> maybe shaun's example is more about seat types rather than locations... ;)
>
> /audi/a8/w12/seats/sports
> /audi/a8/w12/seats/comfort
> /audi/a8/w12/seats/standard
>
> either way, the point is that node names should as meaningful as
> possible in their given context (parent).
>
> On 7/9/07, David Nuescheler <da...@gmail.com> wrote:
> > Hi Shaun,
> >
> > thanks for your feedback.
> >
> > > Our model includes various SNS and while 'yes' I agree that [1],[2]
> etc
> > > aspect can cause problems how else would you model anonymous
> composition
> > > where Object A contains multiple instances of Object B, where Object B
> has
> > > no unique & distinguishing concept of a name.
> > > For example,
> > > [acme:Car]
> > > acme:seats multiple acme:Seat
> > > What would be your preferred way to model the above in a green field
> model?
> >
> > I agree with Felix on using a subnode.
> >
> > If I read Felix's recommendation we would end up with
> > something like:
> >
> > /mercedes/s-class/s-500/seats/0
> > /mercedes/s-class/s-500/seats/1
> > /mercedes/s-class/s-500/seats/2
> >
> > Based on the idea that arbitrary numbers hardly ever
> > qualify as a "good name", I would probably go further
> > in leveraging my hierarchy and use something like:
> >
> > /mercedes/s-class/s-500/seats/driver
> > /mercedes/s-class/s-500/seats/passenger
> > /mercedes/s-class/s-500/seats/back-left
> >
> > I think this adds context for people navigating
> > the hierarchy. Even for people searching the
> > content repository and for whatever reason finding a
> > "seat", they will automatically know that they are looking
> > at a drivers seat of an s-500 mercedes without any
> > further information beyond the path.
> >
> > In my mind this context information is a valuable asset
> > and therefore should not be given away lightly.
> >
> > It may well be that I misunderstood the "seat" example,
> > so please let me know if this all makes sense.
> >
> > regards,
> > david
> >
> > > -----Original Message-----
> > > From: David Nuescheler [mailto:david.nuescheler@gmail.com]
> > > Sent: 07 July 2007 12:17
> > > To: users@jackrabbit.apache.org
> > > Subject: DM Rule #4: Beware of Same Name Siblings.
> > >
> > > Explanation
> > > ---
> > > While Same Name Siblings (SNS) have been introduced into the spec to
> > > allow compatibility with data structures that are designed for and
> > > expressed through XML and therefore are extremely valuable to JCR, SNS
> > > come with a substantial overhead and complexity for the repository.
> > >
> > > Any path into the content repository that contains an SNS in one of
> > > its path segments becomes much less stable, if an SNS is removed or
> > > reordered, it has an impact on the paths of all the other SNS and
> > > their children.
> > >
> > > For import of XML or interaction with existing XML SNS maybe necessary
> > > and useful but I have never used SNS, and never will in my "green
> > > field" data models.
> > >
> > > Example:
> > > ---
> > > Use
> > >
> > > /content/myblog/posts/what_i_learned_today
> > > /content/myblog/posts/iphone_shipping
> > >
> > > instead of
> > >
> > > /content/blog[1]/post[1]
> > > /content/blog[1]/post[2]
> > >
> > >
> >
>
--
Best,
Mark Waschkowski
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Raphael Wegmueller <ra...@gmail.com>.
maybe shaun's example is more about seat types rather than locations... ;)
/audi/a8/w12/seats/sports
/audi/a8/w12/seats/comfort
/audi/a8/w12/seats/standard
either way, the point is that node names should as meaningful as
possible in their given context (parent).
On 7/9/07, David Nuescheler <da...@gmail.com> wrote:
> Hi Shaun,
>
> thanks for your feedback.
>
> > Our model includes various SNS and while 'yes' I agree that [1],[2] etc
> > aspect can cause problems how else would you model anonymous composition
> > where Object A contains multiple instances of Object B, where Object B has
> > no unique & distinguishing concept of a name.
> > For example,
> > [acme:Car]
> > acme:seats multiple acme:Seat
> > What would be your preferred way to model the above in a green field model?
>
> I agree with Felix on using a subnode.
>
> If I read Felix's recommendation we would end up with
> something like:
>
> /mercedes/s-class/s-500/seats/0
> /mercedes/s-class/s-500/seats/1
> /mercedes/s-class/s-500/seats/2
>
> Based on the idea that arbitrary numbers hardly ever
> qualify as a "good name", I would probably go further
> in leveraging my hierarchy and use something like:
>
> /mercedes/s-class/s-500/seats/driver
> /mercedes/s-class/s-500/seats/passenger
> /mercedes/s-class/s-500/seats/back-left
>
> I think this adds context for people navigating
> the hierarchy. Even for people searching the
> content repository and for whatever reason finding a
> "seat", they will automatically know that they are looking
> at a drivers seat of an s-500 mercedes without any
> further information beyond the path.
>
> In my mind this context information is a valuable asset
> and therefore should not be given away lightly.
>
> It may well be that I misunderstood the "seat" example,
> so please let me know if this all makes sense.
>
> regards,
> david
>
> > -----Original Message-----
> > From: David Nuescheler [mailto:david.nuescheler@gmail.com]
> > Sent: 07 July 2007 12:17
> > To: users@jackrabbit.apache.org
> > Subject: DM Rule #4: Beware of Same Name Siblings.
> >
> > Explanation
> > ---
> > While Same Name Siblings (SNS) have been introduced into the spec to
> > allow compatibility with data structures that are designed for and
> > expressed through XML and therefore are extremely valuable to JCR, SNS
> > come with a substantial overhead and complexity for the repository.
> >
> > Any path into the content repository that contains an SNS in one of
> > its path segments becomes much less stable, if an SNS is removed or
> > reordered, it has an impact on the paths of all the other SNS and
> > their children.
> >
> > For import of XML or interaction with existing XML SNS maybe necessary
> > and useful but I have never used SNS, and never will in my "green
> > field" data models.
> >
> > Example:
> > ---
> > Use
> >
> > /content/myblog/posts/what_i_learned_today
> > /content/myblog/posts/iphone_shipping
> >
> > instead of
> >
> > /content/blog[1]/post[1]
> > /content/blog[1]/post[2]
> >
> >
>
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by David Nuescheler <da...@gmail.com>.
Hi Shaun,
thanks for your feedback.
> Our model includes various SNS and while 'yes' I agree that [1],[2] etc
> aspect can cause problems how else would you model anonymous composition
> where Object A contains multiple instances of Object B, where Object B has
> no unique & distinguishing concept of a name.
> For example,
> [acme:Car]
> acme:seats multiple acme:Seat
> What would be your preferred way to model the above in a green field model?
I agree with Felix on using a subnode.
If I read Felix's recommendation we would end up with
something like:
/mercedes/s-class/s-500/seats/0
/mercedes/s-class/s-500/seats/1
/mercedes/s-class/s-500/seats/2
Based on the idea that arbitrary numbers hardly ever
qualify as a "good name", I would probably go further
in leveraging my hierarchy and use something like:
/mercedes/s-class/s-500/seats/driver
/mercedes/s-class/s-500/seats/passenger
/mercedes/s-class/s-500/seats/back-left
I think this adds context for people navigating
the hierarchy. Even for people searching the
content repository and for whatever reason finding a
"seat", they will automatically know that they are looking
at a drivers seat of an s-500 mercedes without any
further information beyond the path.
In my mind this context information is a valuable asset
and therefore should not be given away lightly.
It may well be that I misunderstood the "seat" example,
so please let me know if this all makes sense.
regards,
david
> -----Original Message-----
> From: David Nuescheler [mailto:david.nuescheler@gmail.com]
> Sent: 07 July 2007 12:17
> To: users@jackrabbit.apache.org
> Subject: DM Rule #4: Beware of Same Name Siblings.
>
> Explanation
> ---
> While Same Name Siblings (SNS) have been introduced into the spec to
> allow compatibility with data structures that are designed for and
> expressed through XML and therefore are extremely valuable to JCR, SNS
> come with a substantial overhead and complexity for the repository.
>
> Any path into the content repository that contains an SNS in one of
> its path segments becomes much less stable, if an SNS is removed or
> reordered, it has an impact on the paths of all the other SNS and
> their children.
>
> For import of XML or interaction with existing XML SNS maybe necessary
> and useful but I have never used SNS, and never will in my "green
> field" data models.
>
> Example:
> ---
> Use
>
> /content/myblog/posts/what_i_learned_today
> /content/myblog/posts/iphone_shipping
>
> instead of
>
> /content/blog[1]/post[1]
> /content/blog[1]/post[2]
>
>
RE: DM Rule #4: Beware of Same Name Siblings.
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Shaun,
In this case, I would add an intermediate collection node:
[acme:Car]
+ acme:seatList SeatList
[acme:SeatList]
+ * acme:Seat
You may then name your acme:Seat nodes however you like, e.g. numbering
them or in a coordinate system or by random number or whatever, without
"polluting" the namespace of the acme:Car node. In this case consider
the acme:SeatList sort of an array of acme:Seat nodes where you are free
to assign indices.
Regards
Felix
Am Samstag, den 07.07.2007, 15:55 +0100 schrieb sbarriba:
> Hi David et al,
> Interesting comment on SNS.
>
> Our model includes various SNS and while 'yes' I agree that [1],[2] etc
> aspect can cause problems how else would you model anonymous composition
> where Object A contains multiple instances of Object B, where Object B has
> no unique & distinguishing concept of a name.
>
> For example,
>
> [acme:Car]
> acme:seats multiple acme:Seat
>
> What would be your preferred way to model the above in a green field model?
>
> Regards,
> Shaun
>
> -----Original Message-----
> From: David Nuescheler [mailto:david.nuescheler@gmail.com]
> Sent: 07 July 2007 12:17
> To: users@jackrabbit.apache.org
> Subject: DM Rule #4: Beware of Same Name Siblings.
>
> Explanation
> ---
> While Same Name Siblings (SNS) have been introduced into the spec to
> allow compatibility with data structures that are designed for and
> expressed through XML and therefore are extremely valuable to JCR, SNS
> come with a substantial overhead and complexity for the repository.
>
> Any path into the content repository that contains an SNS in one of
> its path segments becomes much less stable, if an SNS is removed or
> reordered, it has an impact on the paths of all the other SNS and
> their children.
>
> For import of XML or interaction with existing XML SNS maybe necessary
> and useful but I have never used SNS, and never will in my "green
> field" data models.
>
> Example:
> ---
> Use
>
> /content/myblog/posts/what_i_learned_today
> /content/myblog/posts/iphone_shipping
>
> instead of
>
> /content/blog[1]/post[1]
> /content/blog[1]/post[2]
>
RE: DM Rule #4: Beware of Same Name Siblings.
Posted by sbarriba <sb...@yahoo.co.uk>.
Hi David et al,
Interesting comment on SNS.
Our model includes various SNS and while 'yes' I agree that [1],[2] etc
aspect can cause problems how else would you model anonymous composition
where Object A contains multiple instances of Object B, where Object B has
no unique & distinguishing concept of a name.
For example,
[acme:Car]
acme:seats multiple acme:Seat
What would be your preferred way to model the above in a green field model?
Regards,
Shaun
-----Original Message-----
From: David Nuescheler [mailto:david.nuescheler@gmail.com]
Sent: 07 July 2007 12:17
To: users@jackrabbit.apache.org
Subject: DM Rule #4: Beware of Same Name Siblings.
Explanation
---
While Same Name Siblings (SNS) have been introduced into the spec to
allow compatibility with data structures that are designed for and
expressed through XML and therefore are extremely valuable to JCR, SNS
come with a substantial overhead and complexity for the repository.
Any path into the content repository that contains an SNS in one of
its path segments becomes much less stable, if an SNS is removed or
reordered, it has an impact on the paths of all the other SNS and
their children.
For import of XML or interaction with existing XML SNS maybe necessary
and useful but I have never used SNS, and never will in my "green
field" data models.
Example:
---
Use
/content/myblog/posts/what_i_learned_today
/content/myblog/posts/iphone_shipping
instead of
/content/blog[1]/post[1]
/content/blog[1]/post[2]
Re: DM Rule #4: Beware of Same Name Siblings.
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
I completely agree with this asset and would even go one step further:
Do not use SNS under any circumstances unless you know exaclty what you
are doing and are prepared for tons of problems. So about the only use
case for SNS I could imagine is actually importing an XML file into a
item hierarchy, which is never individually modified.
This is my very personal opinion based on very bad experience with SNS.
Regards
Felix
Am Samstag, den 07.07.2007, 13:16 +0200 schrieb David Nuescheler:
> Explanation
> ---
> While Same Name Siblings (SNS) have been introduced into the spec to
> allow compatibility with data structures that are designed for and
> expressed through XML and therefore are extremely valuable to JCR, SNS
> come with a substantial overhead and complexity for the repository.
>
> Any path into the content repository that contains an SNS in one of
> its path segments becomes much less stable, if an SNS is removed or
> reordered, it has an impact on the paths of all the other SNS and
> their children.
>
> For import of XML or interaction with existing XML SNS maybe necessary
> and useful but I have never used SNS, and never will in my "green
> field" data models.
>
> Example:
> ---
> Use
>
> /content/myblog/posts/what_i_learned_today
> /content/myblog/posts/iphone_shipping
>
> instead of
>
> /content/blog[1]/post[1]
> /content/blog[1]/post[2]