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 installations 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 "acme:bar". * 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 property. 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 "acme:bar" * reregister Type acme:A having removed the definition of "acme:bar_tmp" All thoughts welcome, Regards, Shaun -----Original Message----- From: Stefan Guggisberg [mailto:[EMAIL PROTECTED] Sent: 02 August 2007 10:04 To: [email protected] Subject: Re: Adding new node types On 8/1/07, Krenn, Christian <[EMAIL PROTECTED]> 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. http://thread.gmane.org/gmane.comp.apache.jackrabbit.user/2374/focus=2418 http://thread.gmane.org/gmane.comp.apache.jackrabbit.user/536/focus=539 http://thread.gmane.org/gmane.comp.apache.jackrabbit.user/659/focus=664 cheers stefan > > 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:[EMAIL PROTECTED] > Sent: Mittwoch, 01. August 2007 11:11 > To: [email protected] > 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 >
