You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by "E.W. van der Steen" <e....@rug.nl> on 2009/03/13 15:15:59 UTC
Structured mixin-types added to a nt:unstructured node
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"
--
drs. Eric Wout van der Steen
Rijksuniversiteit Groningen / CIT
tel. (050) 3639299
http://www.rug.nl/cit
Re: Structured mixin-types added to a nt:unstructured node
Posted by Torgeir Veimo <to...@pobox.com>.
On 13 Mar 2009, at 16:08, E.W. van der Steen wrote:
> My question still remains. "And if nt:unstructured nodes cannot be
> partly structured using mixin types, how would do "Data first,
> structure later?"."
It would be natural that the primary type of a node overrides any
mixin type of a node? Did you try changing the primary nodetype before
saving the changes?
--
Torgeir Veimo
torgeir@pobox.com
Re: Structured mixin-types added to a nt:unstructured node
Posted by "E.W. van der Steen" <e....@rug.nl>.
Hi Stefan and Torgeir,
Stefan Guggisberg wrote:
> On Fri, Mar 13, 2009 at 4:08 PM, E.W. van der Steen
> <e....@rug.nl> wrote:
>> Stefan Guggisberg wrote:
>>> hi eric
>>>
>>> On Fri, Mar 13, 2009 at 3:15 PM, E.W. van der Steen
>>> <e....@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: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
Re: Structured mixin-types added to a nt:unstructured node
Posted by Stefan Guggisberg <st...@gmail.com>.
On Fri, Mar 13, 2009 at 4:08 PM, E.W. van der Steen
<e....@rug.nl> wrote:
> Stefan Guggisberg wrote:
>>
>> hi eric
>>
>> On Fri, Mar 13, 2009 at 3:15 PM, E.W. van der Steen
>> <e....@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
>
Re: Structured mixin-types added to a nt:unstructured node
Posted by "E.W. van der Steen" <e....@rug.nl>.
Stefan Guggisberg wrote:
> hi eric
>
> On Fri, Mar 13, 2009 at 3:15 PM, E.W. van der Steen
> <e....@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 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?"."
Greetings,
Eric
--
drs. Eric Wout van der Steen
Rijksuniversiteit Groningen / CIT
tel. (050) 3639299
http://www.rug.nl/cit
Re: Structured mixin-types added to a nt:unstructured node
Posted by Stefan Guggisberg <st...@gmail.com>.
hi eric
On Fri, Mar 13, 2009 at 3:15 PM, E.W. van der Steen
<e....@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.
setting the same property on a nt:unstructured node obviously succeeds
since nt:unstructured allows properties of any name and any type.
cheers
stefan
>
> --
> drs. Eric Wout van der Steen
> Rijksuniversiteit Groningen / CIT
> tel. (050) 3639299
> http://www.rug.nl/cit
>
>