jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Abley <james.ab...@gmail.com>
Subject Best practice for evolving models
Date Thu, 20 Aug 2009 10:37:14 GMT

We have an established application using Jackrabbit (1.4.x, moving to 1.6.x)
for persistence that has been running for a while. Running in production has
highlighted some deficiencies in our model which we'd like to address.

e.g. we'd like to add something like the mix:lastModified mixin from JCR 2.0
to some of the node types in our model.

Some node types in our model already use a jcr:lastModified property to
store that sort of information. Other node types use our:lastModified (a
property in a custom-namespace for our application).

This has lead to messy code of the form

if (node.isNodeType(a) || node.isNodeType(b)) {
   node.setProperty("jcr:lastModified", Calendar.getInstance());
else if (node.isNodeType(c)) {
   node.setProperty("our:lastModified", Calendar.getInstance());

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.
   2. Write a migration script to convert existing instances of nodes to
   have the new mixin, and set the relevant property.
   3. Alter our existing code base to just check for
   node.isNodeType("mix:lastModified") before setting the jcr:lastModified
   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. What about the
fact that the primary type of some of the nodes already has a
jcr:lastModified property?



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message