jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: DM Rule #4: Beware of Same Name Siblings.
Date Tue, 10 Jul 2007 06:31:43 GMT
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 <raphael.wegmueller@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 <david.nuescheler@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]
> > > >
> > > >
> > >
> >
> 
> 
> 


Mime
View raw message