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 #7: ID's are evil.
Date Sat, 07 Jul 2007 14:49:29 GMT
Hi David,

[Very useful set of DM Rules by the way!]

"so there really is no need to come up with an additional means of
identifying a node in a stable fashion"

We had one requirement that prompted us to introduce an instance of a
numeric 'id' field that is managed using the Sequence node solution. Our
requirement was for a unique id that referenced a particular class of nodes.
This id was to be used as a HTTP parameter. UUIDs are too large and unwieldy
for our application. Furthermore we wanted to control the format and UUIDs
may change format in the future.

Introducing this solved the requirement but has caused is various headaches
of ensuring when saving, importing etc that the ids remain unique. I'm not
aware of any alternative solutions with JCR? 

Regards,
Shaun

-----Original Message-----
From: David Nuescheler [mailto:david.nuescheler@gmail.com] 
Sent: 07 July 2007 12:35
To: users@jackrabbit.apache.org
Subject: DM Rule #7: ID's are evil.

Explanation:
---
In relational databases IDs are a necessary means to express
relations, so people tend to use them in content models as well.
Mostly for the wrong reasons through.

If your content model is full of properties that end in "Id" you
probably are not leveraging the hierarchy properly.

It is true that some nodes need a stable identification throughout
their live cycle. Much fewer than you might think though.
mix:referenceable provides such a mechanism built into the repository,
so there really is no need to come up with an additional means of
identifying a node in a stable fashion.

Keep also in mind that items can be identified by path, and as much as
"symlinks" make way more sense for most users than hardlinks in a unix
filesystem, a path makes a sense for a lot of applications to refer to
a target node.

More importantly, it is _mix_:referenceable, which means that it can
be applied to a node at the point in time when you actually need to
reference it.

So let's say, just because you would like to be able to potentially
reference a node of type "Document" does not mean that your "Document"
nodetype has to extend from mix:referenceable in a static fashion
since it can be added to any instance of the "Document" dynamically.

Example:
---
use:

/content/myblog/posts/iphone_shipping/attachments/front.jpg

instead of:

[Blog]
- blogId
- author

[Post]
- postId
- blogId
- title
- text
- date

[Attachment]
- attachmentId
- postId
- filename
+ resource (nt:resource)


Mime
View raw message