jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@day.com>
Subject Re: Best practice for evolving models
Date Thu, 20 Aug 2009 13:14:07 GMT
On Thu, Aug 20, 2009 at 12:37 PM, James Abley<james.abley@gmail.com> wrote:
> We're envisaging the following steps to evolve the model:
>   1. Alter the existing code base to apply the new mixin when the relevant
>   node types are created, and set both the jcr:lastModified property and
>   our:lastModified property if applicable.

With JCR 2.0, the jcr:lastModified and co properties are autocreated,
so if you set the mix:lastModified mixin, you don't need to set them.

>   2. Write a migration script to convert existing instances of nodes to
>   have the new mixin, and set the relevant property.

With JCR 2.0, these *could* be protected, ie. set automatically, so
beware that you might get an exception on setProperty() (which you
probably want to do anyway to be compatible with a 1.0 repo). The
current Jackrabbit 2.0 trunk does not have them protected (it's
optional by the spec), but might change that later. See [1] and [2].

>   3. Alter our existing code base to just check for
>   node.isNodeType("mix:lastModified") before setting the jcr:lastModified
>   property.
>   4. Optionally, write a migration script to delete the our:lastModified
>   property that is no longer used and may be taking up storage space.
> Is a mixin the best way of doing what I'm suggesting? It feels so, given
> that there's a new mixin in the latest version of the spec.

Sounds good.

> What about the
> fact that the primary type of some of the nodes already has a
> jcr:lastModified property?

No problem, mixin property/child node definitions merge with other
mixins or primary node types.

[1] https://issues.apache.org/jira/browse/JCR-2233
[2] http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-core/src/main/resources/org/apache/jackrabbit/core/nodetype/builtin_nodetypes.cnd?view=co


Alexander Klimetschek

View raw message