Alex, thanks a lot for your answer! Now, extending nt:file is exactly what I'm currently doing to be able to add more properties to 'standard' (nt:file) JCR files. I didn't know about the mixing thing and WebDAV compatibility, thanks for the tip! (WebDAV support is in our future plans).
I'll read about defining mixing types, I guess it's the same as other node types. OTOH, in my question I forgot to mention that the arbitrary properties requirement was a runtime requirement as opposed to a development requirement. So, when I develop I cannot know in advance the property names. I was thinking that I could add a property like this: - my:props (string) multiple to store arbitrary properties at runtime in the key:value form (that is, each string in @my:props will be "key:value"), then searching for them somehow... will this have a big impact on performance when searching? Is this the recommended way to store not-known-at-development-time properties? Thanks in advance (again) Alexander Klimetschek escribió: > On Tue, Sep 23, 2008 at 10:12 PM, Fabián Mandelbaum > <[EMAIL PROTECTED]> 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: > http://wiki.apache.org/jackrabbit/DavidsModel > > > Regards, > Alex > >
