jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "sbarriba" <sbarr...@yahoo.co.uk>
Subject How to manage JCR Types with JackRabbit? - a contrast with DDL
Date Mon, 27 Aug 2007 09:28:38 GMT
Hi all,
I agree with recent threads on why not to modify the custom_nodetypes.xml
directly. I personally have not yet found a good resource describing best
practises for managing JCR types with JackRabbit - for example I know there
are some limitations on what reRegisterNodeTypes() can achieve. So I've
tried to list common type operations below to prompt discussion on how types
should be managed in JackRabbit - and determine if the type management
should/could be enhanced to avoid the need for migration scripts. 

I've detailed 6 use cases below using a relational DDL analogy - I recognise
that JCR is not trying to emulate a relational DB but there are similarities
in the complexities encountered.

Use Case 1: "Create Table" Master
Use Case 2: "Create Table" Incremental
Use Case 3: "Drop Table"
Use Case 4: "Alter Table Drop Column"
Use Case 5: "Alter Table Add Column"
Use Case 6: "Alter Table modify Column"

The use cases reference an ACME JCR repository including a number of types.
I've included Q: questions on areas of debate.

Use Case 1: "Create Table" Master
For an empty workspace its sufficient to:
 * create a master ACME .cnd file with all of the required types (Type
acme:A, Type acme:B)
 * call NodeTypeManagerImpl.registerNodeTypes()	

Use Case 2: "Create Table" Incremental
If I decide to add a new type (Type acme:C) to an existing JCR repository
its sufficient to:
 * create a fragment .cnd file with the new type (Type acme:C)
 * call NodeTypeManagerImpl.registerNodeTypes()	
 * I also need to add Type acme:C to my master acme.cnd file for clean

Use Case 3: "Drop Table"
I decide I no longer need "Type acme:A". In DDL I'd write a drop table
script and I'd have to ensure my table is not the target of any foreign key
constraint. In JCR I think I just need to:
 * call NodeTypeRegistry.unregisterNodeType()	

Looking at the implementation I don't believe this currently deletes
instances of Type acme:A that exist, leaving me with the requirement to
write a custom migration script to navigate the repository deleting
instances of this type.

Q1: Should unregisterNodeType delete instances of that type, and fail if the
deleting any instances breaks a constraint?

Use Case 4: "Alter Table Drop Column"
It is a common requirement to drop properties you no longer need e.g. drop
property "acmne:foo" from Type acme:A. As with "Drop table" I think you
currently have to:
 * write and run a migration script which iterates through all instances of
Type acme:A and delete the property,
 * call reRegisterNodeType() passing the new definition of "Type acme:A"
minus "acme:foo".

Q2: Does reRegisterNodeType() currently allow you to drop properties?
Q3: Should calling reRegisterNodeType() automatically drop properties that
were present in the old definition but not in the new?

Use Case 5: "Alter Table Add Column"
As with "Drop Column" there is common required to add new properties e.g.
add property "acme:bar" to Type acme:A. I think you currently have to:
* call reRegisterNodeType() passing the new definition of "Type acme:A" with
 * write and run a migration script which iterates through all instances of
Type acme:A and adds the property (if its mandatory)
In DDL the new column would inherit any DEFAULT value assigned to the

Q4: Does reRegisterNodeType() automatically add any "default" values for
newly added properties?

Use Case 6: "Alter Table modify Column"
This is less common, but sometimes you wish to change the type e.g. property
"acme:bar" changes from string to long. This is generally a difficult thing
to do. I presume the only way to deal with this in JCR is to:
 * rereregister Type acme:A with a acme:bar_tmp property with the same
definition as the existing type
 * run a migration script which copies the value of "acme:bar" to
"acme:bar_tmp" and then drops the "acme:bar" property.
 * reregister Type acme:A with definition of "acme:bar" changed.
 * run a migration script which reads "acme:bar_tmp", casts and stores in
 * reregister Type acme:A having removed the definition of "acme:bar_tmp"

All thoughts welcome,

-----Original Message-----
From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com] 
Sent: 02 August 2007 10:04
To: users@jackrabbit.apache.org
Subject: Re: Adding new node types

On 8/1/07, Krenn, Christian <christian.krenn@bearingpoint.com> wrote:
> Hi!
> I had the same problem. There is something that the jackrabbit devs use
> for unit tests. It's in the -> repository/nodetypes. There you have to
> put a file called custom_nodetypes.xml. in the jackrabbit.core.nodetypes
> there is a file called builtin_nodetypes.xml, which you can use as
> template.
> You have also to put a new entry to
> repository/namespace/ns_reg.properties.

note that those files are *not* meant to be user-manipulated. they are
jackrabbit-internal system files. by manually editing those you
may risk data loss/corruption.

see e.g.


> So you needn't to do the registry everytime on the clientside because
> it's automatically done on server startup.
> bye
> -----Original Message-----
> From: shepy [mailto:vladoseprak@yahoo.com]
> Sent: Mittwoch, 01. August 2007 11:11
> To: users@jackrabbit.apache.org
> Subject: Adding new node types
> Hello,
>    I'm using JR as repository server. I need to register new node types.
> Where is the best place to do this? I don't want to do this from client
> application. I see two possibilities:
>   1) Extend RepositoryStartupServlet and do this on init.
>   2) use RepositoryStartupServlet init-param to do this (if it exists)
> Or is there some other possibility?
> Thanks.
> --
> View this message in context:
> http://www.nabble.com/Adding-new-node-types-tf4198867.html#a11942091
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
> The information in this email is confidential and may be legally
privileged. Access to this email by anyone other than the intended addressee
is unauthorized. If you are not the intended recipient of this message, any
review, disclosure, copying, distribution, retention, or any action taken or
omitted to be taken in reliance on it is prohibited and may be unlawful. If
you are not the intended recipient, please reply to or forward a copy of
this message to the sender and delete the message, any attachments, and any
copies thereof from your system.
> BearingPoint INFONOVA GmbH
> Sitz: Unterpremstatten bei Graz
> Firmenbuchgericht: Landesgericht fur ZRS Graz
> Firmenbuchnummer: FN 44354b

View raw message