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 <[EMAIL PROTECTED]> 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.
