On Tue, Aug 17, 2010 at 13:10, Torgeir Veimo <torg...@netenviron.com> wrote: > I dont think this is really obvious for anyone except jackrabbit > developers. I think the code you posted earlier in this thread is the > first example I've ever seen that enables schema updates.
The point of that code is that it handles CND files, as the JCR 2.0 API only allows to work with NodeTypeTemplates when registering/changing node types, but doesn't offer CND code out of the box. The rest is specific to the node types you have and how they are used. > I think the appropriate functionality would be to support 'complex' > schema updates through the normal JCR 2.0 mechanism. Please define "complex". If you think you have cases that could be automatically resolved, but are seen as conflicts, you can report them (the issue above is one of them). If you use the trick with unregistering/registering, for the time where the type is not registered, nodes using it will fall back to nt:unstructured. That will only be a short time span. >> Finally JCR is all about unstructured data,which generally solves the "my >> schema permanently changes and I have change the schema in the >> database/repository" issue. So I completely fail to see your point... > > Aren't you talking about Sling here? JCR and Jackrabbit advertises > schema support, it's only when you dig a bit deeper you see that it's > a one way street, you can configure node types, but you can't change > them when you need to. Except if you're very experienced with > Jackrabbit internal though. Sling just defines a web application layer on top of JCR, it does not change JCR's schema-less support. The issue that changing types is difficult is a conceptual one, independent of the repository/database/storage implementation. There is the old saying that each database schema will evolve into having all fields allowing null and disable all constraints - because it is impossible to anticipate larger changes for the business at a whole. To approach that with Jackrabbit, in my experience you should follow these rules: - only use node types for things that are very fixed (eg. following some standard) - or pre-defined common types such as nt:folder and nt:file (for interoperability of JCR apps) - always inherit from nt:unstructured = allow for residual properties (you never know) - use constraints such as mandatory or value constraints rarely - use mixins (to extend things like nt:folder, or if certain "features" of a content item might change over time) - for user content schemas, you have to handle the schema and its constraints in the UI anyway, hence that's the place to define them; because they change frequently, the underlying storage should not enforce them; code reading that content should always gracefully handle missing pieces as much as possible (the "robustness principle") Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
