hi marco i think your problem is 2-folded:
1. you need modifications to your content structure to reflect the evolution of your app 2. you intend to adjust existing versions of the nodes with that node type As far as 1 is concerned there are different ways to achieve this. from my point of view changing an existing node type definition is not the preferred way as it ultimately leads to 2. Instead I would recommend you any of the following: a. create mixin types and add them to the nodes if your modifications are such that effectively "extends" the existing node type.... like annotations mentioned by chetan. that's exactly how the JCR specification defines mixin types b. if you have breaking changes in your application though, you may consider creating new node types and change the primary type of your nodes to the new types. if Oak works properly it should automatically adjust the child items of the node that gets the primary type changed: adding new autocreated items, redefine existing child items according to the new item definitions and removing all child items that don't have a applicable item definition in the new node type. please file a critical bug in case that wouldn't work. both a. and b. lead to the situation where you don't have to touch the version storage. the older versions of your nodes just reflect that state of that node at that point in the past and the newer versions reflect the updated state. that's how it is intended to work. modification to existing versions is neither intended nor desirable as it effectively runs the version storage meaningless. it's aim actually is to allow you to go back and look at and possible restore an previous state of a given node... if those get modified afterwards there is simply no sense at all in creating versions. as far as other comments regarding node types are concerned: i disagree with the statement that custom node types are evil and to be avoided. we are seeing plenty of issues with unstructured repository content in various areas last but not least when it comes to security. my recommendation would rather be as follows (short version): - use existing or custom node types whenever possible - use residual property and child item definitions in your custom node types for really residual, arbitrary data (e.g. your application doesn't know nor care about the attributes a given user will apply and you don't have to post-process, secure, observe them - use named property and child item definitions for everything that is application logic, is controlled/created/observed/processed by the application or has a special meaning to it. while this approach forces you to properly design not only your application but also your content model, it helps you explicitly establishing a contract for your application. hope that helps angela On 24/07/17 11:19, "Marco Piovesana" <pioves...@esteco.com> wrote: >Hi all, >I'm working on the upgrade module for my application based on Oak. The >module modifies the custom node types to reflect the modifications in the >application. >Some of those modifications may be adding new properties to custom nodes, >and implicitly to all versions of that node. >Since frozen nodes are read-only we ended up recreating the node history. >This, however, makes the system more complex because we have >weak-references between those nodes and recreating the history means new >ids for the versions. >There's really no way to modify the frozen node? There's a better way to >solve this problem? > >Marco.
