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 <[EMAIL PROTECTED]> wrote:
On 7/8/08, Alexander Klimetschek <[EMAIL PROTECTED]> 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 <
[EMAIL PROTECTED]> 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
