jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: DM Rule #4: Beware of Same Name Siblings.
Date Tue, 10 Jul 2007 09:08:03 GMT

On 7/10/07, Tako Schotanus <quintesse@gmail.com> wrote:
> On 7/10/07, Jukka Zitting <jukka.zitting@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.


Jukka Zitting

View raw message