jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@day.com>
Subject Re: Issue while re-registering node types
Date Tue, 17 Aug 2010 13:39:28 GMT
On Tue, Aug 17, 2010 at 13:10, Torgeir Veimo <torgeir@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

> 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")


Alexander Klimetschek

View raw message