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 Thu, 04 Feb 2010 14:20:33 GMT

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.



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

> On Mon, Feb 1, 2010 at 16:04, Davide Maestroni
> <davide.maestroni@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

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