Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of aklimets@day.com designates
 207.126.148.181 as permitted sender)
Message-ID: <c3ac3bad0812190517o50e8d445gd4290657911602ff@mail.gmail.com>
Date: Fri, 19 Dec 2008 14:17:07 +0100
From: "Alexander Klimetschek" <aklimets@day.com>
To: users@jackrabbit.apache.org
Subject: Re: non-hierarchical content
In-Reply-To: <6c59d89a0812190454v2ba82d85qd39dd25b4833ba73@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <6c59d89a0812110640h5a8a6c41g42ef20c6a24a2142@mail.gmail.com>
	 <c3ac3bad0812140825y527c3c1bo79b5c82fa91ba08e@mail.gmail.com>
	 <6c59d89a0812190454v2ba82d85qd39dd25b4833ba73@mail.gmail.com>

On Fri, Dec 19, 2008 at 1:54 PM, Torsten Curdt <tcurdt@apache.org> wrote:
>> (standard property names for this purpose, will be
>> included as mix:title mixin in JCR 2.0) for the tags.
>
> Why "mix:title"?

Because it gives you mainly the jcr:title property and the additional,
but probably less uses jcr:description property. See section 4.7.23.8
of the current JSR-283 preview.

> So would advice against using the UUIDs in the multivalue field?

You could and you can have referential integrity with it (using the
REFERENCE property type) - to already answer your question about ref.
integrity from below. But as JCR does not have something like a "On
Delete Cascade", you will have to manually remove all the references
to a target node before you can delete it.

But why do you need referential integrity for tagging? It's not a
critical thing.

And imagine you have different rights for tags and content, ie. there
is some content that a tagging administrator (aka the "librarian")
cannot access (eg. the personal files of the boss). What if he wants
to delete a tag (aka also delete all its references on the content)?
He can't, so you need a solution for a smooth transition anyway (mark
for delete and delete later when the content owner touches his content
for example).

> But that is awkward. You will end up with tags like this
>
> /tags/oldname/my:title = 'newname'
>
> That's confusing more than it helps.

Why? The title could also be something that does not fit into the JCR
node name constraints, eg. "Apple Pie".

> While we are on that: As JCR quite a bit like filesystem - are there
> native ways of doing a "symbolic link"?

JCR 2.0 will introduce "shareable nodes" which can be seen as hard links.

For symbolic links you have to resolve them yourself (but you can use
the PATH property type to ensure the character constraints for JCR
paths).

> And if so - how does that work with versioned resources?

Not sure, but I think it will always reference the current version of
a target node.

> Hm ... that's a lot of manual work :-/
>
> I think I prefer the lazy show of tags and them prune on the next write maybe.
> So the "weak reference" model. But lack of repository based
> referential integrity assurance is quite a turn off.

Have you looked at rule 5 of David's model:
http://wiki.apache.org/jackrabbit/DavidsModel#head-ed794ec9f4f716b3e53548be6dd91b23e5dd3f3a

It explains why in a JCR you should always try to avoid referential
integrity, because it will always put stones in the way for all the
other benefits you get by using JCR.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com