jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davide Maestroni <davide.maestr...@gmail.com>
Subject Re: Repository migration
Date Mon, 01 Feb 2010 15:04:45 GMT
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 <aklimets@day.com>wrote:

> On Fri, Jan 29, 2010 at 17:26, Davide Maestroni
> <davide.maestroni@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message