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 74.125.44.28 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references:x-google-sender-auth;
        b=Wt4RG9QQ+V4nO7NyTVbwcIRdyPOxtCmy1LGNCAyOb7qKpWqMNL8vVYBJnYvEj7e1fi
         pqZog9t2ykhqsEnU63ByWXk7Do1iaBcx/cJkdZuOfEA3eMwOAkDblw7D8jyn5FbnYFsv
         C6tcxbOOPm08ohFnSF6DTm/bxXtpJm/BmP4sE=
Message-ID: <90a8d1c00807180828v7d233b40hcfcf6066cec5c607@mail.gmail.com>
Date: Fri, 18 Jul 2008 17:28:22 +0200
From: "Stefan Guggisberg" <stefan.guggisberg@day.com>
Sender: stefan.guggisberg@gmail.com
To: users@jackrabbit.apache.org
Subject: Re: Incremental node type update?!?
In-Reply-To: <272c2bf60807081248q2a1bbf2dn399cea1ee4224c4f@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <272c2bf60807080733y6e25fe96jbc85666908236960@mail.gmail.com>
	 <c3ac3bad0807080817k16cb9aal1c3415a53635aa44@mail.gmail.com>
	 <ffd6aaa90807081230o6390a3e0qacc6c11506721554@mail.gmail.com>
	 <272c2bf60807081248q2a1bbf2dn399cea1ee4224c4f@mail.gmail.com>

hi nick

On Tue, Jul 8, 2008 at 9:48 PM, Nick Stuart <nstuart@speranzasystems.com> wrote:
> Thats what I am hoping Toby. Any of our changes would be adding a property
> or something like that, not changing the previous properties. The one thing
> I'm afraid of is if we find a new requirement 6 months down the road and
> want to add a new property to stuff we are storing in JackRabbit, none of
> our old stuff will work. I just don't see anything throught the NodeManager
> API to accomplish this.
>
> In this particular case all I wanted to do was add a new property to an
> existing node type. Right now the stuff we are storing are mostly types of
> nt:folder and nt:file, so going with nt:unstructured really isn't an option.
> I have setup our own custom node types that have a set of mixins on them
> extending nt:file/folder, which works just great. I just want to know that
> down the road those mixins can be updated to add a new property or
> something.
>
> Obviously I know some changes just can't happen (node type removal,
> required/default values change etc) as I can see those would just not work
> with existing data, but would love it if adding a property or something of
> the like was available.
>
> -Nick
>
> On 7/8/08, Tobias Bocanegra <tobias.bocanegra@day.com> wrote:
>>
>> On 7/8/08, Alexander Klimetschek <aklimets@day.com> wrote:
>> > Hi Nick,
>> >
>> >  if you want a flexible data structure, go with nt:unstructured. Only
>> >  use node types and mixins for things you know that are fixed and for
>> >  which you want to search for easily ( //element(*, my:nodetype) ). In
>> >  this case you have to re-create content and re-register node types
>> >  from scratch. But a good JCR application creates its initial node
>> >  types and content model upon first startup with an empty repository
>> >  anyway. For reset, you can simply delete the workspace folder (if it
>> >  contains the persistence manager data such as derby files) except for
>> >  the workspace.xml, and it will get recreated on the next startup of
>> >  Jackrabbit.
>> >
>>
>> >  On Tue, Jul 8, 2008 at 4:33 PM, Nick Stuart <
>> nstuart@speranzasystems.com> wrote:
>> >  > Is there a way to update node types without have to delete your entire
>> >  > repository and start over? I dont see a lot of methods on the
>> >  > NodeTypeManager to allow for really any kind of operation besides
>> >  > registering types.
>> >  >
>> >  > This can't really be an unforseen problem as I imagine data structures
>> are
>> >  > going to change everywhere, so I think I must be missing something. If
>> I try
>> >  > to register node types that already exist I of course get an error say
>> its
>> >  > already there.
>>
>>
>> if the nodetype change is compatible with the existing one, i.e.
>> adding a new property or childnode definition, relaxing a constraint,
>> etc, the node type can be reregistered.

trivial node type modifications are already supported.
for more details see:
http://jackrabbit.apache.org/api-1/org/apache/jackrabbit/core/nodetype/NodeTypeDefDiff.html
http://issues.apache.org/jira/browse/JCR-322.

here you'll find some sample code using node type definitions in CND/XML format:
http://code.google.com/p/jackrabbit-jcr-demo/wiki/RegisterNodeTypes

if you want to build the node type definition programmatically you can use
http://jackrabbit.apache.org/api/1.4/org/apache/jackrabbit/core/nodetype/NodeTypeManagerImpl.html#registerNodeType(org.apache.jackrabbit.core.nodetype.jsr283.NodeTypeDefinition,%20boolean)

BTW this method will probably be included in the JCR 2.0 API.

cheers
stefan

>>
>> regards, toby
>>
>