You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by James Abley <ja...@gmail.com> on 2009/08/20 12:37:14 UTC
Best practice for evolving models
Hi,
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
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. What about the
fact that the primary type of some of the nodes already has a
jcr:lastModified property?
Cheers,
James
Re: Best practice for evolving models
Posted by Stefan Guggisberg <st...@gmail.com>.
On Thu, Aug 20, 2009 at 3:14 PM, Alexander Klimetschek<ak...@day.com> wrote:
> On Thu, Aug 20, 2009 at 12:37 PM, James Abley<ja...@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.
not quite. only if the declaring node types of the existing and the 'new'
jcr:lastModified property are identical. otherwise the mixin assignment
will fail due to a name conflict.
cheers
stefan
>
> [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
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
>
Re: Best practice for evolving models
Posted by Alexander Klimetschek <ak...@day.com>.
On Thu, Aug 20, 2009 at 12:37 PM, James Abley<ja...@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
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com