Hi Angela, Thanks for your exhaustive reply. I do understand your point regarding version management, however I do not totally agree when you say that "*modification to existing versions is neither intended nor desirable as it effectively runs the version storage meaningless*". The final user of course should not be able to modify the store version information, but talking about an application that uses Oak as a library (my case), is i believe a different story. Let me use an example to explain what I mean: in a later version of the application we want to extend the information available on a specific custom type (e.g. the number of words in a text file), we weren't interested in that value before, but we are now because of some new features. We want to add that property to our custom type, but we also want to add it to all its versions, because it's a time-consuming task and we don't want to calculate it every time we access that type of node. In this scenario we don't want to modify the meaning of the information already stored in a version, but we want to extend the information with something that was already there but was ignored. After the modification the user can still go back to a previous version and the meaning of it is preserved. >From my point of view, blocking the modification of the history even for the system that uses Oak as a library, makes its usage far more complicated in terms of upgrade without any true benefit in terms of security. What do you think?
Marco. On Fri, Aug 4, 2017 at 9:25 AM, Angela Schreiber <anch...@adobe.com.invalid> wrote: > 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. > >
