jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Waschkowski" <mwaschkow...@gmail.com>
Subject Re: DM Rule #4: Beware of Same Name Siblings.
Date Mon, 09 Jul 2007 20:16:26 GMT
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]
> > >
> > >
> >
>



-- 
Best,

Mark Waschkowski

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message