baseline/configuration sub-tree as frozen-node rep:version references?

[rosselet <at...@gmail.com>]

>From looking at the code, and trying to figure out how the configuration node
works,  am I correct that at least currently the configuration node doesn't
actually store a subtree consisting of references to the node versions at
the time of the config being commited, but rather a LIST of these frozennode
references?

in VersionManagerConfigImpl.java  
commit does this:
                    Set<NodeId> baseVersions = collectBaseVersions(state);
                    InternalValue[] vs = new
InternalValue[baseVersions.size()];
                    int i=0;
                    for (NodeId id: baseVersions) {
                        vs[i++] = InternalValue.create(id);
                    }
                    state.setPropertyValues(NameConstants.REP_VERSIONS,
PropertyType.REFERENCE, vs);
which appears to support what I have seen: multivalued "rep:versions"
property with UUID references to the correct frozen nodes for that point in
time.  

Is there currently any way to get this as a "sub-tree", or can I at least
assume that the sub-tree was walked breadth-first? (are parents ensured to
always appear in this multivalue list before children?)

or.. am I missing something completely????
thanx
Ati

--
View this message in context: http://jackrabbit.510166.n4.nabble.com/baseline-configuration-sub-tree-as-frozen-node-rep-version-references-tp3920033p3920033.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.

Re: baseline/configuration sub-tree as frozen-node rep:version references?

[rosselet <at...@gmail.com>]

Jukka,
Aha.. so I'm not completely off in left field.. good. I think.
So basically, to be able to reconstruct the structure at a given
configuration version, I would have to add extra information to the nodes -
for instance an order index to retain child ordering, and/or our node type
(to determine parent/child relationships).  In our case we need multiple
"snapshots" to be able to state that when a new version of parent (A) was
committed (some change), exactly which subnodes and what version of those
subnodes were currently "active" - to be able to get a point in time state
of the tree.  Luckily we're only talking about a 2-3 level deep sub-node
with a multiplicity only at the bottom level... so I guess we can manually
reconstruct the tree from the frozon node references.  

I had assumed that this was not just for restoring PIT snapshots, but also
for accessing and using the different PIT snapshot versions (if we didn't
need to be able to independantly add new versions of the nodes at each
level, I'd just go with only versioning the root of the subnode and using
OVP=COPY).

Again.. thank you. Having the source code really helps, but confirmation
from someone who knows what that code DOES (or is supposed to do :)) is
great.
Cheers
Ati Rosselet

--
View this message in context: http://jackrabbit.510166.n4.nabble.com/baseline-configuration-sub-tree-as-frozen-node-rep-version-references-tp3920033p3920357.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.

Re: baseline/configuration sub-tree as frozen-node rep:version references?

[alex <al...@gmail.com>]

Jukka Zitting <jukka.zitting <at> gmail.com> writes:

> 
> Hi,
> 
> On Wed, Oct 19, 2011 at 10:32 PM, rosselet <ati.rosselet <at> gmail.com> 
wrote:
> > Is there currently any way to get this as a "sub-tree", or can I at least
> > assume that the sub-tree was walked breadth-first? (are parents ensured to
> > always appear in this multivalue list before children?)
> 
> The set of version references in a baseline isn't supposed to contain
> any structural information. The only thing a baseline does is to
> record the current version of all versionable nodes within a
> configuration (typically a subtree).
> 
> Note that a configuration/baseline is not enough to reconstruct a
> given subtree from scratch. Restoring a recorded baseline requires
> that the subtree already exists with all the relevant versionable
> nodes in place, and restoring the baseline just restores each of those
> versionable nodes to the versions recorded in the baseline.
> 
> BR,
> 
> Jukka Zitting
> 
> 

Hi,

I tried to create a baseline, but it failed, because one of the child node is 
not versionable (its OPV is COPY).

Is this the correct behaviour ? I cannot find anything in the specification
that required that all nodes in the subgraph must be versionable.

Regards,

Alexandre Maurel

Re: baseline/configuration sub-tree as frozen-node rep:version references?

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Wed, Oct 19, 2011 at 10:32 PM, rosselet <at...@gmail.com> wrote:
> Is there currently any way to get this as a "sub-tree", or can I at least
> assume that the sub-tree was walked breadth-first? (are parents ensured to
> always appear in this multivalue list before children?)

The set of version references in a baseline isn't supposed to contain
any structural information. The only thing a baseline does is to
record the current version of all versionable nodes within a
configuration (typically a subtree).

Note that a configuration/baseline is not enough to reconstruct a
given subtree from scratch. Restoring a recorded baseline requires
that the subtree already exists with all the relevant versionable
nodes in place, and restoring the baseline just restores each of those
versionable nodes to the versions recorded in the baseline.

BR,

Jukka Zitting