On 18.06.11 17:52, "David Buchmann" <[email protected]> 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: http://wiki.apache.org/jackrabbit/DavidsModel 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... Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
