jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Launay <sebastien.lau...@anyware-tech.com>
Subject Re: Incremental node type update?!?
Date Wed, 09 Jul 2008 08:54:02 GMT
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 <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.
>>
>> regards, toby
>>
>>     

Mime
View raw message