You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Nick Stuart <ns...@speranzasystems.com> on 2008/07/08 16:33:03 UTC
Incremental node type update?!?
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.
Thanks for the help!
-Nick
Re: Incremental node type update?!?
Posted by Stefan Guggisberg <st...@day.com>.
On Fri, Jul 18, 2008 at 10:04 PM, Nick Stuart
<ns...@speranzasystems.com> wrote:
> One question though, I noticed the NodeTypeManagerImpl doesn't let you
> specify the type of input stream you are feeding it on the two register
> methods. Does this mean its always going to want an XML file?
how about this one?
http://jackrabbit.apache.org/api/1.4/org/apache/jackrabbit/core/nodetype/NodeTypeManagerImpl.html#registerNodeTypes(java.io.InputStream,%20java.lang.String,%20boolean)
contentType is one of the following:
JackrabbitNodeTypeManager.TEXT_X_JCR_CND
JackrabbitNodeTypeManager.TEXT_XML
cheers
stefan
>
> If so thats kind of a pain....
>
Re: Incremental node type update?!?
Posted by Nick Stuart <ns...@speranzasystems.com>.
One question though, I noticed the NodeTypeManagerImpl doesn't let you
specify the type of input stream you are feeding it on the two register
methods. Does this mean its always going to want an XML file?
If so thats kind of a pain....
Re: Incremental node type update?!?
Posted by Nick Stuart <ns...@speranzasystems.com>.
Blah, nevermind I see the allowUpdate flag on there now....yeah for
reading....
On Fri, Jul 18, 2008 at 3:52 PM, Nick Stuart <ns...@speranzasystems.com>
wrote:
> Ok, the NodeTypeDefDiff gets me part of the way there, but how do I go
> about updating my existing data with that info? JCR-322 just talks about the
> inability to perform Non-Trivial updates, which I'm not concerned with at
> the moment.
>
> Will I still need to go through and unregister/register my NodeTypes, and
> assume I will loose the data with those?
>
> Thanks for the links and references!
> -Nick
>
>
>
>>
>>
>> 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)<http://jackrabbit.apache.org/api/1.4/org/apache/jackrabbit/core/nodetype/NodeTypeManagerImpl.html#registerNodeType%28org.apache.jackrabbit.core.nodetype.jsr283.NodeTypeDefinition,%20boolean%29>
>>
>> BTW this method will probably be included in the JCR 2.0 API.
>>
>> cheers
>> stefan
>>
>> >>
>> >> regards, toby
>> >>
>> >
>>
>
>
Re: Incremental node type update?!?
Posted by Nick Stuart <ns...@speranzasystems.com>.
Ok, the NodeTypeDefDiff gets me part of the way there, but how do I go about
updating my existing data with that info? JCR-322 just talks about the
inability to perform Non-Trivial updates, which I'm not concerned with at
the moment.
Will I still need to go through and unregister/register my NodeTypes, and
assume I will loose the data with those?
Thanks for the links and references!
-Nick
>
>
> 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)<http://jackrabbit.apache.org/api/1.4/org/apache/jackrabbit/core/nodetype/NodeTypeManagerImpl.html#registerNodeType%28org.apache.jackrabbit.core.nodetype.jsr283.NodeTypeDefinition,%20boolean%29>
>
> BTW this method will probably be included in the JCR 2.0 API.
>
> cheers
> stefan
>
> >>
> >> regards, toby
> >>
> >
>
Re: Incremental node type update?!?
Posted by Stefan Guggisberg <st...@day.com>.
hi nick
On Tue, Jul 8, 2008 at 9:48 PM, Nick Stuart <ns...@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 <to...@day.com> wrote:
>>
>> On 7/8/08, Alexander Klimetschek <ak...@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
>>
>
Re: Incremental node type update?!?
Posted by Sébastien Launay <se...@anyware-tech.com>.
Hi Nick,
If you have complete control on your node type definitions,
there is a dirty hack to reregister a node type definition.
I'm using it because some times you do not have a choice but i
think this is definitely dirty and must be used with caution :).
You need to:
- stop your applicaton
- delete the file repository/nodetypes/custom_nodetypes.xml
- start your application which must register all the nodetype
definitions (the new one and others previously defined)
- maybe update the nodes or properties accordingly to the new nodetype
In the following cases you need to migrate the data before using the
repository in order to avoid ConstraintViolationException on save():
- after adding a new mandatory property you must set the default value
on all nodes
- the removal of a mandatory property (respectively node) can be done
like this:
- a new definition must be registered where this property
(respectively node) is now optional
- then this property (respectively node) must be deleted on target nodes
- finally a new definition must be registered where this property
(respectively node) does not exists anymore
- the change of the type of a typed property (like Date to String)
(respectively change of child node type) can be done like this:
- a new definition must be registered where this property
(respectively node) is now optional (if it was mandatory)
- then this property (respectively node) must be deleted on target nodes
- a new definition must be registered where the property type
(respectively child node type) has changed
- finally this property (respectively node) must be set on target
nodes (if this property is mandatory)
I have developed a tool for automatically process these operations
just after repository startup by keeping the current revision in a
property of the root node like the schema_info table in Ruby on Rails
migration [1] and by using Groovy scripts for migrating data and setting
default values.
It works well with standalone repository.
But in clustering mode, it causes non fatal exceptions and the node
types definitions must be reregistered at each repository startup on
all cluster nodes except the one where the migration is done...
[1] http://wiki.rubyonrails.org/rails/pages/UnderstandingMigrations
--
Sébastien Launay
Nick Stuart a écrit :
> 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 <to...@day.com> wrote:
>
>> On 7/8/08, Alexander Klimetschek <ak...@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.
>>
>> regards, toby
>>
>>
Re: Incremental node type update?!?
Posted by Nick Stuart <ns...@speranzasystems.com>.
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 <to...@day.com> wrote:
>
> On 7/8/08, Alexander Klimetschek <ak...@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.
>
> regards, toby
>
Re: Incremental node type update?!?
Posted by Tobias Bocanegra <to...@day.com>.
On 7/8/08, Alexander Klimetschek <ak...@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 <ns...@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.
regards, toby
Re: Incremental node type update?!?
Posted by Alexander Klimetschek <ak...@day.com>.
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.
Regards,
Alex
On Tue, Jul 8, 2008 at 4:33 PM, Nick Stuart <ns...@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.
>
> Thanks for the help!
>
> -Nick
>
--
Alexander Klimetschek
alexander.klimetschek@day.com