jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Curdt" <tcu...@apache.org>
Subject Re: non-hierarchical content
Date Fri, 19 Dec 2008 19:18:16 GMT
>> 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

Mime
View raw message