Hi David, I have the issue of creating a caching system, where I have my cache entries, which have dependencies of certain data. Of course, I would not create REFERENCEs to the real data to not lock down the user managing the data. But how about creating a mirror hierarchy of data to which the cache entries REFERENCE.
In this case, when the real data is modified I can lookup the mirror and find the referring cache entries. The nice thing of having a REFERENCE property in this case is, that I can get the referents from the data (actually the mirro of it) node without having to employ a heavy weight search. What do you think ? Regards Felix Am Samstag, den 07.07.2007, 13:20 +0200 schrieb David Nuescheler: > 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.
