>> So in order to find the published content you would have to lookup the >> published UUID (or version). In pseudo code: >> >> published = /articles/article1/@published >> publishedArticle = /articles/article1[version == $published] >> >> ...or duplicate the content for the publication. > > I would rather copy published articles into another workspace or even > another repository that holds the "live" publish content. Content that > is "live" and actively used should IMHO not be put in versions.
May I ask why you would not use a version of a node? Any particular reasons? >>> Even RDMS cannot guarantee 100% integrity, so dangling references are >>> something that an application should expect. >> >> Huh? That's what foreign key constraints are for. Those things you >> hate when you just want to get rid of this one row and have to touch >> table after table ;) > > I heard enough examples of (major) databases where the foreign key > constraint was broken after a crash or other problem. Ouch! Seems like I was lucky so far then. >> True ... I still think it would be nice to at least be able to have >> this somehow be integrated into JCR as well. Not necessarily as >> constraints like with databases. But give it some time and you will >> want to cleanup the data mess that has piled up. Would be nice if >> there was a standard way of cleaning that up. Maybe even just lazily. > > Did I mention observation as a way to handle the "cascading"? For many > things in JCR it is rather useful to copy it to a separate location > (de-normalized) and this can happen with an observation listener. Embracing the duplication :) > In the case of tagging you can have an observation listener to handle the > deletion of references that don't exist. For example, if someone sets > the tags property to "green" and "blue", but there is only a > "/tags/green", the listener would make sure the property will only be > set to "green". Hmmm ....interesting! Thanks, Alex! cheers -- Torsten
