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. > 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 >
