You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Michael Marth <mm...@adobe.com.INVALID> on 2017/08/01 19:40:38 UTC
Re: frozen node modifications
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" <pi...@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.
Re: frozen node modifications
Posted by Marco Piovesana <pi...@esteco.com>.
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 <mm...@adobe.com.invalid>
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" <pi...@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.
>
--
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.
Re: frozen node modifications
Posted by Marco Piovesana <pi...@esteco.com>.
Dear Mehrotra,
I think I got your point, when using unstructured nodes I loose all
benefits of, for example, an hierarchical structure. However I still don't
understand the part regarding the versions, and how the use of
unstructured, or loosely structured nodes, will help my problem. Here my
original question:
> *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?*
how can i update those information without having to recreate the whole
version history again?
Marco.
On Wed, Aug 2, 2017 at 8:55 AM, Chetan Mehrotra <ch...@gmail.com>
wrote:
> > it is preferable to not create custom node types, because typically the
> business requirements are not understood enough
>
> Nodetypes are helpful as "content annotation" and allow repository to
> provide better performance by relying on them for indexing,
> observation, bundling etc. So may be better to say avoid nodetypes
> with restrictive definition. However do create new nodetype (or
> mixins) to mark the domain objects in your application content.
>
> Chetan Mehrotra
>
--
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.
Re: frozen node modifications
Posted by Chetan Mehrotra <ch...@gmail.com>.
> it is preferable to not create custom node types, because typically the business requirements are not understood enough
Nodetypes are helpful as "content annotation" and allow repository to
provide better performance by relying on them for indexing,
observation, bundling etc. So may be better to say avoid nodetypes
with restrictive definition. However do create new nodetype (or
mixins) to mark the domain objects in your application content.
Chetan Mehrotra