jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tako Schotanus" <quinte...@gmail.com>
Subject Re: DM Rule #5: References considered harmful.
Date Tue, 10 Jul 2007 08:35:16 GMT
I think this goes directly against the directive of using meaningful
path names. Meaningful path names are only useful if they actually
reflect the data they "point to" and with data normally not being
static this means that you should take into account that you will have
to change your node names or move your nodes regularly. The moment you
do this you could possibly have left your repository with lots of
dangling references. The only way to prevent this would be to use
generated node names and a hierarchy that doesn't reflect the actual
relationship between parent and child nodes, which would defeat the
purpose of having a hierarchical repository in the first place.

That doesn't mean I think you should UUIDs instead, I'm just pointing
out a problem that I encountered myself.

In my latest designs I just tend to do something like this:

/myapp/config/users/joe
/myapp/config/users/jane
/myapp/config/users/tarzan

/myapp/docs/some-doc1/@owner = 'jane'

where I just refer to the specific nodes in the users section and to
find those users I have a special configuration section:

/myapp/config/paths/users = '/myapp/config/users'

and I "bootstrap" the app by pointing it to "/myapp/config/paths".
This way my application is completely independent of paths because I
don't like the idea that I can't move things around.

I would rather have used paths, but without referential integrity I
don't see much use except for the fact that you know it's not just any
string.


On 7/7/07, David Nuescheler <david.nuescheler@gmail.com> wrote:
> Explanation
> ---
> References imply referential integrity. I find it important to
> understand that references do not just add additional cost for the
> repository managing the referential integrity, but they also are
> costly from a content flexibility perspective.
>
> Personally I make sure I only ever use references when I really cannot
> deal with a dangling reference and otherwise use a path, a name or a
> string UUID to refer to another node.
>
> Example
> ---
> Let's assume I allow "references" from a document (a) to another
> document (b). If I model this relation using reference properties this
> means that the two documents are linked on a repository level. I
> cannot export/import document (a) individually, since the reference
> property's target may not exist. Other operations like merge, update,
> restore or clone are affected as well.
>
> So I would either model those references as "weak-references" (in JCR
> v1.0 his essentially boils down to string properties that contain the
> uuid of the target node) or simply use a path. Sometimes the path is
> more meaningful to begin with.
>
> I think there are usecases where a system really can't work if a
> reference is dangling, but I just can't come up with a good "real" yet
> simple example from my direct experience.
>

Mime
View raw message