Hi Michael, thanks for your comment. We started our project using node types but yes, recently we also thought about moving to a "schemaless" structure because of the struggling we had when trying to modify the data structure. However I still don't quite understand how can this solve my problem with versioned nodes. I mean: if a node is unstructured i can add or remove any property from node without any problem, but i can't do that to its versions right? If i need to apply a calculated value to each version, so that i don't have to make that calculation any time i retrieve that version information, how can i do that?
Marco. On Tue, Aug 1, 2017 at 9:40 PM, Michael Marth <[email protected]> wrote: > 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" <[email protected]> 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. > -- marco piovesanA Enterprise Application *ESTECO* | EXPLORE DESIGN PERFECTION AREA Science Park, Padriciano 99 - 34149 Trieste - ITALY Phone: +39 040 3755548 - Fax: +39 040 3755549 [Website] <http://www.esteco.com> | [Twitter] <https://twitter.com/esteco_mF> | [Facebook] <https://www.facebook.com/esteco.spa> | [Linkedin] <https://www.linkedin.com/company/748217> Pursuant to Legislative Decree No. 196/2003, you are hereby informed that this message contains confidential information intended only for the use of the addressee. If you are not the addressee, and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you. Please consider the environment before printing this email.
