Hi Stefan and Torgeir,
Stefan Guggisberg wrote:
On Fri, Mar 13, 2009 at 4:08 PM, E.W. van der Steen
<[email protected]> wrote:
Stefan Guggisberg wrote:
hi eric
On Fri, Mar 13, 2009 at 3:15 PM, E.W. van der Steen
<[email protected]> 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:w3Object2]
- 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!
Eric
--
drs. Eric Wout van der Steen
Rijksuniversiteit Groningen / CIT
tel. (050) 3639299
http://www.rug.nl/cit
