jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@adobe.com>
Subject Re: CndImporter
Date Mon, 20 Jun 2011 10:46:06 GMT
On 18.06.11 17:52, "David Buchmann" <david.buchmann@liip.ch> wrote:
>you can update the type definition, but only adding new stuff, never
>removing (or renaming) any properties. and you can't delete a node type
>once you have registered it.

You can remove a node type through the nt registry (the CND importer does
not do this, so you'd need to write custom code for those nt changes) and
then add the new version of it right afterwards. AFAIK Jackrabbit "falls"
back to nt:unstructured for content using such unknown node types in the
mean time.

This gives a few more upgrade options, however you might still have
incompatible changes to the type...

>i think this is a bit surprising, but it means you have to make sure you
>test your stuff very well before you apply a cnd to a production system.

... as that's a general problem with all schemas (including database
schemas). Once content uses certain properties, constraints etc., you
can't just exchange them.

That's why using nt:unstructured has many advantages - data first,
structure later:

Using node types only for things where the probability of change in the
future is very, very low, such as for very standardized elements.
nt:file/nt:folder are good examples for that. You can still extend with
mixins later. Since JCR 2.0, you can also change the primary node type of
a node (Node.setNodeType()), however it is not very useful for an evolving
node type, since you'd have to encode the versioning schema inside the
node type name ;-)

>the only way we found to get rid of a custom node type was to completely
>delete the jackrabbit folder.

Or delete only the content that uses those node types and
recreate/reimport it (for the development process where you continuously
might update your nt, but existing data can be thrown away).

But the above still holds true...


Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

View raw message