jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Klimetschek" <aklim...@day.com>
Subject Re: Arbitrary key:value property pairs node type
Date Wed, 24 Sep 2008 07:58:37 GMT
On Tue, Sep 23, 2008 at 10:12 PM, Fabián Mandelbaum
<fmandelbaum@gmail.com> wrote:
>    "I'd like to add arbitrary
> tags/properties/attributes/whatever_you_want_to_call_em to a content
> node (read: a file stored in JCR). For example I'd like to add property
> project:A and property project:B to mean that my file belongs to both
> project A and project B, in a way that I can list files of project B by
> searching for all files with project:B property. I don't know in advance
> if it will be project:A, project:B, project:XXX, project:whatever."
>    Is there a way to do this? To make a node type that accepts
> arbitrary (there may be other requirements besides projects, otherwise,
> a multi-valued property named project would suffice) Java Map-like
> property key:value pairs ...

Yes, unstructured data is one of the key features of JCR ;-) If you
allow any properties, these are called "residual". The most prominent
built-in jcr node type that supports this is nt:unstructured (allows
both any properties and any child nodes). To build your own node type,
see http://jackrabbit.apache.org/node-types.html. If you want to
attach it to an nt:file or nt:resource, you could either extend
nt:file with a new node type allowing residual properties, or write a
mixin that allows them and add this mixin to all your nt:file or
nt:resource nodes (the latter is more compatible with other apps
accessing the repository, eg. the WebDAV server).

> ...which is also searchable using standard JCR
> XPath expressions (Like in gimme all nodes having key=value)?

Yes, no problem: /jcr:root//*[key='value']

>    Or should I just make sure that all prossible properties are defined
> for that node? If I do this, and in V2 of my app I find out that I need
> more/less properties, will I have to write a tool to migrate data
> between V1 and V2 repositories of my app?

If you know that it is not very fixed and you need to migrate/change
data later, unstructured is probably better. Especially if you only
attach to nt:file nodes, ie. nodes that already have a distinct node
type (which can be better for searching: element(*, nt:file)).

You might want to look at our content modeling wiki page from the main
author of the JCR spec:


Alexander Klimetschek

View raw message