jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "sbarriba" <sbarr...@yahoo.co.uk>
Subject RE: DM Rule #4: Beware of Same Name Siblings.
Date Tue, 10 Jul 2007 07:30:40 GMT
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]
>
>


Mime
View raw message