Re: Repository migration

[Alexander Klimetschek <ak...@day.com>]

On Fri, Jan 29, 2010 at 17:26, Davide Maestroni
<da...@gmail.com> wrote:
> I wonder if there exists a built-in mechanism to safely updating the nodes
> when their type is being changed. What I have in mind is a sort of converter
> to register when the type modifications are committed, so to handle the
> cases where a node would be no more consistent with its own type.
> Can you suggest a way to achieve what I have just describe?

If a node type referenced by a node is no longer available (because it
was unregistered, eg. for upgrading the node type), it should fall
back to "nt:unstructured". If the definitions no longer match, you
might get constraint exceptions upon the next modification of that
node (if that modification doesn't "fix" it, eg. by mixins etc.).

In general, the best solution to cope with evolving node types is to
always use nt:unstructured as base type for your custom node types (or
place the residual definitions yourself). And refrain from mandatory
properties and child nodes as much as possible. Then you are not
forced to update your node types.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: Repository migration

[Davide Maestroni <da...@gmail.com>]

Alex,

thank you for your help, your support has been very useful!

Regards,

Davide

On Thu, Feb 4, 2010 at 3:56 PM, Alexander Klimetschek <ak...@day.com>wrote:

> On Thu, Feb 4, 2010 at 13:20, Davide Maestroni
> <da...@gmail.com> wrote:
> > What I want to know is if I can fix a node by just overwriting it. If,
> for
> > example, the property of a node becomes mandatory, and a node already
> exist
> > without any value set for it, can I just fix it by explicitly (not in the
> > node type definition) setting a value for the missing property?
>
> Yes, this should work fine. Mandatory constraints are checked upon
> save(). Only property allowed, type and value constraints are checked
> upon setting the property. AFAIK you should also be able to remove
> properties that are no longer allowed by the new node type.
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
>

Re: Repository migration

[Alexander Klimetschek <ak...@day.com>]

On Thu, Feb 4, 2010 at 13:20, Davide Maestroni
<da...@gmail.com> wrote:
> What I want to know is if I can fix a node by just overwriting it. If, for
> example, the property of a node becomes mandatory, and a node already exist
> without any value set for it, can I just fix it by explicitly (not in the
> node type definition) setting a value for the missing property?

Yes, this should work fine. Mandatory constraints are checked upon
save(). Only property allowed, type and value constraints are checked
upon setting the property. AFAIK you should also be able to remove
properties that are no longer allowed by the new node type.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: Repository migration

[Alexander Klimetschek <ak...@day.com>]

On Thu, Feb 4, 2010 at 13:20, Davide Maestroni
<da...@gmail.com> wrote:
> What I want to know is if I can fix a node by just overwriting it. If, for
> example, the property of a node becomes mandatory, and a node already exist
> without any value set for it, can I just fix it by explicitly (not in the
> node type definition) setting a value for the missing property?

Yes, this should work fine. Mandatory constraints are checked upon
save(). Only property allowed, type and value constraints are checked
upon setting the property. AFAIK you should also be able to remove
properties that are no longer allowed by the new node type.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: Repository migration

[Davide Maestroni <da...@gmail.com>]

Alex,

thank you again.
I understand that the nodes are evaluated only on writing, what is not so
clear to me is which is the node version to be evaluated for constraint
violations. Let me make an example: let's say node A is stored in the
repository and I want to make some changes to its properties; let's say that
the changes can be represented with node B and let's say that the original
node after the modifications (A+B) is called C. Which is the evaluated node?
A, B or C? I.e. the original one stored in the repository, the changes to be
applied, or the node after the changes?

What I want to know is if I can fix a node by just overwriting it. If, for
example, the property of a node becomes mandatory, and a node already exist
without any value set for it, can I just fix it by explicitly (not in the
node type definition) setting a value for the missing property? Or, as soon
as I try to save the modification I'll got an exception.

Thanks,

Davide



On Mon, Feb 1, 2010 at 4:31 PM, Alexander Klimetschek <ak...@day.com>wrote:

> On Mon, Feb 1, 2010 at 16:04, Davide Maestroni
> <da...@gmail.com> wrote:
> > thank you very much for your quick response. I understand that forcing
> > constraints in node types is not advisable when I foresee evolving
> > structures, though I would like to be able to 'fix' data automatically
> when,
> > for example, an application requires specific properties to exist (even
> with
> > default values).
>
> You can use auto-created properties with default-values for that.
> These should not be a blocker for future schema evolvement, if
> residual property definitions are present, as they are only evaluated
> upon creating the parent node.
>
> Main problems with evolving schemas:
> - node type inheritance changes
> - mandatory properties that no longer should be mandatory
> - new properties are added
> - required primary types for child nodes
>
> Therefore using those constraints should only be done when you are
> sure that the model is complete and doesn't have to change in the
> future. Or could be easily replaced by a completely new node type
> later.
>
> > Now I have another question in mind: is there a way to intercept the data
> as
> > soon as they are read from the persistent storage and before they are
> > processed by Jackrabbit?
>
> As I said, if you change node types, existing nodes won't necessarily
> be re-evaluated until the next time data is written. There is no
> constraint checking on reads (AFAIK).
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
>

Re: Repository migration

[Alexander Klimetschek <ak...@day.com>]

On Mon, Feb 1, 2010 at 16:04, Davide Maestroni
<da...@gmail.com> wrote:
> thank you very much for your quick response. I understand that forcing
> constraints in node types is not advisable when I foresee evolving
> structures, though I would like to be able to 'fix' data automatically when,
> for example, an application requires specific properties to exist (even with
> default values).

You can use auto-created properties with default-values for that.
These should not be a blocker for future schema evolvement, if
residual property definitions are present, as they are only evaluated
upon creating the parent node.

Main problems with evolving schemas:
- node type inheritance changes
- mandatory properties that no longer should be mandatory
- new properties are added
- required primary types for child nodes

Therefore using those constraints should only be done when you are
sure that the model is complete and doesn't have to change in the
future. Or could be easily replaced by a completely new node type
later.

> Now I have another question in mind: is there a way to intercept the data as
> soon as they are read from the persistent storage and before they are
> processed by Jackrabbit?

As I said, if you change node types, existing nodes won't necessarily
be re-evaluated until the next time data is written. There is no
constraint checking on reads (AFAIK).

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: Repository migration

[Davide Maestroni <da...@gmail.com>]

Alex,

thank you very much for your quick response. I understand that forcing
constraints in node types is not advisable when I foresee evolving
structures, though I would like to be able to 'fix' data automatically when,
for example, an application requires specific properties to exist (even with
default values).

Now I have another question in mind: is there a way to intercept the data as
soon as they are read from the persistent storage and before they are
processed by Jackrabbit?

The workaround, I would like to implement, consists in wrapping an existing
persistent storage with my own, so to be able to fetch the data from the
real storage, eventually transform them (updating also the stored ones), and
only then pass the result to Jackrabbit. Do you believe this could be a good
solution? Can you suggest me a better way to do that?

Thank you again,

Davide


On Mon, Feb 1, 2010 at 2:28 PM, Alexander Klimetschek <ak...@day.com>wrote:

> On Fri, Jan 29, 2010 at 17:26, Davide Maestroni
> <da...@gmail.com> wrote:
> > I wonder if there exists a built-in mechanism to safely updating the
> nodes
> > when their type is being changed. What I have in mind is a sort of
> converter
> > to register when the type modifications are committed, so to handle the
> > cases where a node would be no more consistent with its own type.
> > Can you suggest a way to achieve what I have just describe?
>
> If a node type referenced by a node is no longer available (because it
> was unregistered, eg. for upgrading the node type), it should fall
> back to "nt:unstructured". If the definitions no longer match, you
> might get constraint exceptions upon the next modification of that
> node (if that modification doesn't "fix" it, eg. by mixins etc.).
>
> In general, the best solution to cope with evolving node types is to
> always use nt:unstructured as base type for your custom node types (or
> place the residual definitions yourself). And refrain from mandatory
> properties and child nodes as much as possible. Then you are not
> forced to update your node types.
>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
>