Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of stefan.guggisberg@gmail.com
 designates 209.85.128.191 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=ezoYDtFjB/V/nVkJihl6MHfTvlK3vPJaPmIU8KjiSBUYAE95yB6obhlkgtMbcGxTfIoXk6eJu+D0rsLUTMXjeZUVhYYaX1kjoe7xMOZl22eFs9eQJNdqV5cEzMG+MR1JxfiX/2556JOAWC+JraXRiVyRfREyB7B5Mz5WxBJtCkY=
Message-ID: <90a8d1c00709080515l19c43a22h33a4f25db58b239c@mail.gmail.com>
Date: Sat, 8 Sep 2007 14:15:33 +0200
From: "Stefan Guggisberg" <stefan.guggisberg@gmail.com>
To: users@jackrabbit.apache.org
Subject: Re: How to manage JCR Types with JackRabbit? - a contrast with DDL
In-Reply-To: <008e01c7eff6$c624eb10$526ec130$@co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <11942091.post@talk.nabble.com>
	 <DF465686F70C4E4BBBDCC80AB2F4C830748FED@becxoex04.corp.kpmgconsulting.com>
	 <90a8d1c00708020204w297b90depbaddf8da297a194e@mail.gmail.com>
	 <001b01c7e88c$a642ce50$f2c86af0$@co.uk>
	 <008e01c7eff6$c624eb10$526ec130$@co.uk>

hi shaun,

On 9/5/07, sbarriba <sbarriba@yahoo.co.uk> wrote:
> Hi all,
> I was hoping to drive out a best practise for JackRabbit type management on
> this thread but no takers yet.

well, you hit a soft spot... ;-)

comments follow inline

> Anyone got any interesting comments ......
> ..... or are there better solutions out there for CND management that I'm
> missing?
> Regards,
> Shaun.
>
> -----Original Message-----
> From: sbarriba [mailto:sbarriba@yahoo.co.uk]
> Sent: 27 August 2007 10:29
> To: users@jackrabbit.apache.org
> Subject: How to manage JCR Types with JackRabbit? - a contrast with DDL
>
> 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.

personally i think node type modifications should be fully supported.
currently only a subset of operations is implemented, namely those that don't
affect existing content (e.g. adding non-manadatory properties etc).

those operations that do affect existing content (like removing a
property definition)
are IMO very hard to implement and we haven't yet found an elegant way
of tackling the involved complexity/issues.

>
> 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.

the current implementation doesn't (yet) support node type deregistration.

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

IMO yes. but that's exactly the tricky part. you'd need an exclusive lock
over the entire repository and you'd need find all occurrences in every
workspace  (potentially containing a *lot* of items)...

>
> 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?

currently no.

> Q3: Should calling reRegisterNodeType() automatically drop properties that
> were present in the old definition but not in the new?

yes. see previous comment.

>
> 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?

no.

>
> 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,

sorry for the late response.

cheers
stefan

> Regards,
> Shaun
>
>
>
> -----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.
> 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: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
> >
>
>