jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Structured mixin-types added to a nt:unstructured node
Date Fri, 13 Mar 2009 15:21:03 GMT
On Fri, Mar 13, 2009 at 4:08 PM, E.W. van der Steen
<e.w.van.der.steen@rug.nl> wrote:
> Stefan Guggisberg wrote:
>> hi eric
>> On Fri, Mar 13, 2009 at 3:15 PM, E.W. van der Steen
>> <e.w.van.der.steen@rug.nl> wrote:
>>> Hi all,
>>> We're preparing for a migration to JCR and have read up on David's Model
>>> on content modelling. We are going to embrace "Data first, structure
>>> later (maybe)", but we want to be prepared for the "structure later", so
>>> we did some testing. We're looking into what happens if you add a mixin
>>> to already stored nodes, and I came across some unexpected behaviour.
>>> When adding a mixin-type to a node of type nt:unstructured, it seems
>>> that no type validation is done on the properties that are defined in
>>> the mixin-type.
>>> I could not clearly read in the specification whether this is as it
>>> should be. I guess nt:unstructured means that even if you add a
>>> mixin-type which requires structure, that will not really happen?
>>> Could someone clarify this for me for better understanding of the model?
>>> And if nt:unstructured nodes cannot be partly structured using mixin
>>> types, how would do "Data first, structure later?".
>>> I added my actions below as a reference.
>>> Thanks in advance,
>>> Eric
>>> My actions:
>>> I uploaded a XML-file through WEBDav in a newly created repository using
>>> the 1.5 Jackrabbit webapp release. This creates a node of type nt:file,
>>> with a childnode jcr:content of type nt:unstructured.
>>> Then I defined the following mixin-type:
>>> <rugcms = 'http://webplatform.rug.nl/jcr'>
>>> [rugcms:w3Object]
>>> mixin
>>> - rugcms:type (long) mandatory
>>> - rugcms:status (long) = '5' mandatory
>>> and added this mixin to the jcr:content node:
>>> testNode.addMixin("rugcms:w3Object");
>>> testNode.setProperty("rugcms:type", Calendar.getInstance());
>>> testNode.setProperty("rugcms:status", "published");
>>> followed by a save(). The properties are added without exceptions.
>>> But if I add it to the file node (type nt:file), this fails on the
>>> setProperty() with the following error as expected:
>>> javax.jcr.ValueFormatException: conversion failed: String to Long:
>>> conversion to long failed: For input string: "published": conversion to
>>> long failed: For input string: "published": For input string: "published"
>> well the exception is pretty clear:
>> you're trying to set a property of type 'long' to a non-numeric string
>> value,
>> hence the vlaue format exception.
> Yes, very clear, and as I would expect as mentioned.
>> setting the same property on a nt:unstructured node obviously succeeds
>> since nt:unstructured allows properties of any name and any type.
> But that means the added mixin-type is ignored, which I would not expect as

in jcr, adding a mixin 'complements' the existing primary type, it
doesn't 'override'
it. if you set a property, an applicable property definition is searched.

in your case, the rugcms:status is not applicable because the types are
incompatible. the residual property definition in nt:unstructured does
match your property.

> it makes adding structure later more difficult. My question still remains.
> "And if nt:unstructured nodes cannot be partly structured using mixin types,
> how would do "Data first, structure later?"."

try NodeImpl.setPrimaryType(String); it will be available in the JCR 2.0 api
once jsr 283 has been finalized (which should be a matter of a couple
of months).

> Greetings,
> Eric
> --
> drs. Eric Wout van der Steen
> Rijksuniversiteit Groningen / CIT
> tel. (050) 3639299
> http://www.rug.nl/cit

View raw message