We don't have (yet) a similar configuration option in 3.x which allows a CND file to be loaded at startup. Could you please open a feature request for that in JIRA ?
Regarding the schema update, I'm not sure I understand what you mean by "migration of the schema to the new version"
How do I get a schema.cnd file to load up when a repository is configured in 3.0 with jboss as7?
It is possible to register node types by casting the javax.jcr.nodetype.NodeTypeManager to org.modeshape.jcr.api.nodetype.NodeTypeManager, which extends the standard interface and adds several methods for registering node types using a stream (or resolvable URL or java.io.File) to your CND file. We think this is a bit better than specifying it in the configuration file, since your application probably needs some sort of repository initialization logic anyway.
But as Horia said, we can add a way to specify it via the configuration file.
P.S. Is there an update site for the CND editor eclipse plugin or do I need to build it myself?
We do have a temporary update site, but we're discussing with several other projects related to JBoss Tools to figure out a permanent URL.
Here's the temporary URL that will change in a few weeks:
We'll make a wider announcement when we have the final and permanent URL.
In production it is often necessary to update a schema and the sort of changes can range from minor things like name or type changes of attributes to major re-organisations of the structure. Some support to help with these migrations would be useful.
At a minimum, The ability to have the schema in the configuration and to specify a mode to validate it against the existing schema in the repository would be a very useful safety check for upgrades (similar to how hibernate's hibernate.hbm2ddl.auto property works).
Beyond that it gets more complicated the more that is changed. For example
- I might change a name of a node or attribute in the schema and want to update the repository with the new names as specified in the new schema.
- I may add a node into a heirarchy and require a migration of the nodes in the current repository to introduce the new node.
and so on.
For the moment I would do this by writing migration code that has to be run before the upgrade is completed but it would be a nice feature for production systems to be able to specify this as a mapping from the old to new schemas. Probably asking too much but that was what I was thinking about when I asked the question. Schema specification in the configuration and an option to either create OR validate it would be a very useful first step.
Great info. Thanks!
I was just talking to a colleague the other day who is updating one of our products that uses modeshape 2.8.1. She needs to add an attribute to one of the nodes in an existing system and would rather not reload all the data.
If this was an SQL database she would just run a bit of DDL (alter table xyx add fred varchar not null default "abc") and it would be done.
There isn't an equivalent in modeshape (or AFAIK the JCR standard) but in a production system I think that this is essential functionality. We can write a bit of java to do it and deploy/run that as part of a migration but this is quite clumsy.
I just had a thought, are there schema modification commands available over the REST interface? ie: are the (section 19) node type management commands available via REST in 2.8.1 (or in 3.0)?
1 of 1 people found this helpful
We recently added functionality to the REST interface that allows this. There are two forms: one that simply posts the CND file, the other that uses a multi-part form. This will first become available with Beta3.See the 3.x RESTful interface documentation for more details.
With this approach, you can add new node type definitions or override/update existing definitions, but it's not possible to remove node type definitions. It is equivalent to calling "org.modeshape.jcr.api.nodetype.NodeTypeManager.registerNodeTypes(java.io.InputStream)".
It is not possible to use the JCR API or the RESTful service to directly manipulate the nodes representing the node types under "/jcr:system/jcr:nodeTypes", since these are all protected properties and child node definitions.