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
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
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
>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?


On Fri, Aug 4, 2017 at 9:25 AM, Angela Schreiber <anch...@adobe.com.invalid>

> 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.

Reply via email to