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 12:54:40 GMT
> If you need the ability to rename, you should "define" tags in a
> separate location, eg. under /tags. Then you would have a my:Tag node
> type that includes a title (and maybe a description) using jcr:title
> and jcr:description

That's what I thought

> (standard property names for this purpose, will be
> included as mix:title mixin in JCR 2.0) for the tags.

Why "mix:title"?

> A tag would then
> be identified by the node path /tags/flower (or just "flower" if the
> /tags prefix is fixed and known) and now content can be tagged by
> having a multivalue tags property that includes those paths

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

But that is awkward. You will end up with tags like this

/tags/oldname/my:title = 'newname'

That's confusing more than it helps.

While we are on that: As JCR quite a bit like filesystem - are there
native ways of doing a "symbolic link"? And if so - how does that work
with versioned resources? Example:

/articles/article1/images/image1.jpg -> /images/image1.jpg
/articles/article2/images/image1.jpg -> /images/image1.jpg

or with versioning

/images/image1.jpg (versions 1, 2)
/articles/article1/images/image1.jpg -> /images/image1.jpg (version 1)
/articles/article2/images/image1.jpg -> /images/image1.jpg (version 2)
/articles/article3/images/image1.jpg -> /images/image1.jpg (latest)

> (using
> reference properties here could be a little performance issue and are
> not very readable when exploring the content, see David's model, rule
> 5).

But how do you deal with referential integrity here? I remove a tag
from the "tags" node and suddenly the references are dangling. (Ah ...
you cover that below)

> This requires an extra step when displaying content to retrieve
> the actual title of a tag, but that is not a big problem, since the
> tags, which are effectively nodes then, would be managed by
> jackrabbit's internal node cache for free - and if the number of them
> is limited (say a few 10000 tags), this should work out fast.


> Renaming a tag is simple then, simply change the title property of
> your tag. Removing tags and other operations can be either done
> through observation or in a lazy-way. With observation, ie. modify all
> tags properties in the content when you delete a tag, you have the
> problem that there might be a lot of write operations at once. Since
> you have that extra step during display of content anyway, you could
> also do it the lazy way and don't display tags that are not under
> /tags anymore. Removing tags can also be lazy, ie. on the next write
> operation on the content node, again using observation.

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.

I have "referential integrity" on the feature list on some
presentation slides. Right now I just can't follow why/how.

>> 1. Is "mix:versionable" of recursive nature? When this is set on the
>> document node will all the descending-or-self nodes be versioned? Or
>> is this per node?
> There is a separate setting called "OnParentVersion" for node types
> that specifies what happens with a node when its parent is versioned.
> Have a look at section 8.2.11 "OnParentVersion Attribute" of the JCR
> 1.0 specification [2].

Ah - thanks!

>> 2. Why would you want to use "jcr:data" vs "my:body"? That just a
>> convention for e.g. the explorer or webdav servlets? Where could I
>> find information about these standard attributes? Are they defined in
>> the spec?
> With a JCR, you should always try to standardize your property names
> and/or nodetypes. This gives you maximum reuse. The generic (simple)
> WebDAV servlet is only one integration that works with nt:file and
> nt:folder - others are possible. Have a look at rule 6 of David's
> model [3].

Thanks, for the links!!


View raw message