Hi Marco, A better (or at least alternative) way to approach this, is to avoid the problem in the first place :) In my experience it is preferable to not create custom node types, because typically the business requirements are not understood enough - which means you later want to add things and then end up in the situation you just described. You could simply use unstructured nodes and have one String property describe the “type”. A good reason to have node types is if you require the repository to enforce integrity (as opposed to the application doing that).
The unstructured approach is equivalent to the term “schemaless” as it became popular a couple of years ago. Obvs there are pros and cons, so pls take the above as a reflection of what has worked well for me (but your circimstances might be different) Cheers Michael 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.
