jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Klimetschek" <aklim...@day.com>
Subject Re: non-hierarchical content
Date Fri, 19 Dec 2008 18:59:30 GMT
On Fri, Dec 19, 2008 at 7:04 PM, Torsten Curdt <tcurdt@apache.org> wrote:
>> And for someone who explores the
>> repository (developer or administrator) the path
>> /tags/theveniceproject makes more sense than a (UU)ID.
> ...well only when he knows that 'Joost' was 'The Venice Project'
> before. Otherwise there is no difference to a (UU)ID at all.

As I said, it gives at least a hint.

> If someone wants to "delete node 'blue'" then the path is not good
> enough. You will have check the titles.

But you delete the tag "blue" and not the node "blue". This requires
the application to handle that and somewhat reduces the simple changes
you can do manually on the repository itself.

> Because it could well be that
> there exists:
> /tags/blue/my:title = 'green'
> /tags/green/my:title = 'blue'
> While this should not happen I have seen too many stupid things and
> would not rule this out just like that.

Yes, you might be right. Tagging is really a rather difficult thing for JCR ;-)

> 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.

> Right - but my point was that you have to express all that in your
> application's code.

Yes, that's where it gets a bit tricky with JCR.

>> 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.

>> An application that
>> expects corrupt data and can handle it will have more up-time than one
>> that completely breaks in that situation.
> 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. 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".


Alexander Klimetschek

View raw message