jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Nuescheler" <david.nuesche...@gmail.com>
Subject Re: same-name-sibling compaction
Date Tue, 26 Sep 2006 14:00:00 GMT
Hi David,

Personally, I think that there are going to be more volatile and
less volatile paths in a content repository based on many
different characteristics of the application(s) running on the
repository. Generally SNS paths are less stable
because they are not only impacted by "moves" of the node
or an ancestor node but also by removals or additional of
sibling nodes.

I agree with you that, if one requires a stable identification of a node
a path to an SNS node is a poor nodetype design that I would
certainly not recommend. Alternatively I would recommend
to use a referencable node or stay away from SNS.

Personally, I would even go further and state that SNS should
be used in exceptional cases only and with great caution, in

I will gladly forward this post to jsr-283-comments@jcp.org
for discussion in the Expert Group, and would encourage
anyone to post specification enhancement to the above address.


On 9/26/06, David Kennedy <davek@us.ibm.com> wrote:
> I'd like to bring up the issue of compaction of indices with regard to
> same-name-siblings again.  Compaction pretty much renders
> same-name-siblings useless if you refer to nodes via path.  In a muti-user
> environment, and any point one user can move a node, thus changing the
> path of any following sibling referenced by other sessions.  If an
> application maintains proxy data by path reference, the node may exist,
> however with a completely different path.  Either applications need to
> make all nodes referencable and manage via UUID or avoid SNS.  Has the
> EG's direction with regard to SNS compaction changed in JSR-283?
> David

View raw message