jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "E.W. van der Steen" <e.w.van.der.st...@rug.nl>
Subject Re: Structured mixin-types added to a nt:unstructured node
Date Fri, 13 Mar 2009 16:23:24 GMT
Hi Stefan and Torgeir,

Stefan Guggisberg wrote:
> 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.
Ah I see, that explains the behaviour, thanks. Perhaps noteworthy, the 
"mandatory" constaint *is* checked, but that is as expected then.

>> 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).
That does the trick. I've add this definition: (excuse the '2' in the 
name, waiting on JCR 2.0 for that too ;) )

<rugcms = 'http://webplatform.rug.nl/jcr'>
- rugcms:type (long) mandatory
- rugcms:status (long) = '5' mandatory

If I call NodeImpl.setPrimaryType("rugcms:w3Object2"); the primary type 
is changed (if the nodes already existed and were of the right type of 
course). Any properties that were present are left in-tact, but adding 
any other properties that are not defined is not allowed anymore.

So I guess a partial structuring (adding typed constraints) is not 
possible, only a full structuring. This means that when you do this, you 
have to check the Nodes you structure and remove any nodes and 
properties that are not part of the new definition, otherwise you cannot 
export the data and import it again.

Good to know, thanks for the info!
drs. Eric Wout van der Steen
Rijksuniversiteit Groningen / CIT
tel. (050) 3639299

View raw message