You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Jukka Zitting <ju...@gmail.com> on 2008/02/08 16:23:11 UTC
Same name siblings
Hi,
Support for same name siblings is troublesome and currently the best
practice is to avoid them if possible. In many cases the default
response when we see people having problems with SNS is to tell them
not to use the feature.
I think that's lame. We should either treat SNS as a first-class
feature that we just haven't been able to make work yet, or explicitly
deprecate it and plan to drop or at least seriously limit the feature
as far as is permitted by the JCR standard.
The current status where SNS is kind of supported but "you should not
use it!" is IMHO not sustainable in the long run.
WDYT, is SNS worth the effort, or should we consider dropping it?
BR,
Jukka Zitting
Re: Same name siblings
Posted by Stefan Guggisberg <st...@gmail.com>.
hi jukka
On Feb 8, 2008 4:23 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> Support for same name siblings is troublesome and currently the best
> practice is to avoid them if possible. In many cases the default
> response when we see people having problems with SNS is to tell them
> not to use the feature.
i think we have to distinguish between issues related
to the SNS feature in general and issues related to
jackrabbit's implementation of the SNS feature.
the main reason for not using SNS is IMO path instability.
that's an inherent SNS 'feature' and not an implementation issue.
personally i am not aware of SNS implementation issues in jackrabbit
but i might perhaps just ignoring them ;) do you have any particular in mind?
>
> I think that's lame. We should either treat SNS as a first-class
> feature that we just haven't been able to make work yet, or explicitly
> deprecate it and plan to drop or at least seriously limit the feature
> as far as is permitted by the JCR standard.
since SNS are enabled through node types and according to the JCR spec
the minimal requirement for a compliant implementation is nt:base support
we could just choose to not support SNS at all ;)
however, since jackrabbit is the RI, that's IMO unfortunately not an option.
don't get me wrong. i am not advocating SNS use. the SNS feature is IMO
flawed. it was introduced as a compromise in order to enable import of
arbitrary xml documents. i guess we have to live with it.
cheers
stefan
>
> The current status where SNS is kind of supported but "you should not
> use it!" is IMHO not sustainable in the long run.
>
> WDYT, is SNS worth the effort, or should we consider dropping it?
>
> BR,
>
> Jukka Zitting
>
Re: Same name siblings
Posted by Julian Reschke <ju...@gmx.de>.
David Nuescheler wrote:
>>> On the other hand I would really like to give people a means to
>>> work with large anonymous unordered collections.
>>> I think a feature that would address the "I have a bag of objects
>>> and I just want to persist them without thinking of a 'name' for
>>> each" usecase, would definitely be great. Maybe this could
>>> be the introduction of an addNode() without a childnode name.
>> A big +1 on that idea.
>>
>> "Store this and return me a path" would be really useful. Would it make
>> sense to allow the impl to choose the container as well?
> interesting twist, would that be a Session.addNode() vs. a Node.addNode()
> without a node name?
Yes, it would allow the server to choose a location based on the node type.
I guess it would be confusing on Node :-).
BR, Julian
Re: Same name siblings
Posted by David Nuescheler <da...@day.com>.
> > On the other hand I would really like to give people a means to
> > work with large anonymous unordered collections.
> > I think a feature that would address the "I have a bag of objects
> > and I just want to persist them without thinking of a 'name' for
> > each" usecase, would definitely be great. Maybe this could
> > be the introduction of an addNode() without a childnode name.
> A big +1 on that idea.
>
> "Store this and return me a path" would be really useful. Would it make
> sense to allow the impl to choose the container as well?
interesting twist, would that be a Session.addNode() vs. a Node.addNode()
without a node name?
regards,
david
Re: Same name siblings
Posted by Julian Reschke <ju...@gmx.de>.
David Nuescheler wrote:
> On the other hand I would really like to give people a means to
> work with large anonymous unordered collections.
> I think a feature that would address the "I have a bag of objects
> and I just want to persist them without thinking of a 'name' for
> each" usecase, would definitely be great. Maybe this could
> be the introduction of an addNode() without a childnode name.
A big +1 on that idea.
"Store this and return me a path" would be really useful. Would it make
sense to allow the impl to choose the container as well?
> ...
BR, Julian
Re: Same name siblings
Posted by Alex Lukin <lu...@stu.cn.ua>.
Friday 08 February 2008 19:09:55 Alessandro Bologna написав:
[skip]
> So with a little bit of REST architecturale style and some SAX/XSLT on
> top of it, JCR is working great, probably better than we could have
> hoped for. And, lastly, I think that Roy's Fielding vision on the JCR
> was to support this type of use case. I am still digesting the
> deprecation of XPATH in JSR 283, dropping XML support would be a
> little too much.. ;).
>
> So for me is a -1.
>
My applicatins hardly depend on XML import/export feature too, and XPath is natural
lang for JCR used as XML capable store. Deprection of XPath in JSR 283 was a bad surpise for me too.
--
SY, Alex Lukin
RIPE NIC HDL: LEXA1-RIPE
Re: Same name siblings
Posted by Alessandro Bologna <al...@gmail.com>.
Hi,
I agree that it can be messy, and that many people use it for the
wrong purpose, but I would like to mention that a very important use
case for SNS is the ability to import XML and to access individual XML
elements or attributes using JCR APIs.
The DocumentView import is *tremendously* useful when used in a
content processing environment, and I am afraid that dropping support
for SNS all together would drive some of people (like us) that are
currently using Jackrabbit to use just an XMLDB. Besides, if used in
the context of XML, we import documents under a not SNS wrapper (say
article00x, or "myFirstArticle"), and never had an issue with this
approach.
So with a little bit of REST architecturale style and some SAX/XSLT on
top of it, JCR is working great, probably better than we could have
hoped for. And, lastly, I think that Roy's Fielding vision on the JCR
was to support this type of use case. I am still digesting the
deprecation of XPATH in JSR 283, dropping XML support would be a
little too much.. ;).
So for me is a -1.
Alessandro
On Feb 8, 2008 11:10 AM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Feb 8, 2008 5:48 PM, David Nuescheler <da...@day.com> wrote:
> > I think a feature that would address the "I have a bag of objects
> > and I just want to persist them without thinking of a 'name' for
> > each" usecase, would definitely be great. Maybe this could
> > be the introduction of an addNode() without a childnode name.
>
> Good idea! We could also allow "*" as a wildcard child node name in
> the existing addNode() signatures.
>
> > > WDYT, is SNS worth the effort, or should we consider dropping it?
> > I don't think that it is problematic to have some features that are not
> > optimized.
>
> I think the issue runs deeper than just performance. We have at least
> one open issue, JCR-435, and given the fact that we guide people away
> from SNS at the first sings of trouble I wouldn't be surprised if
> there were other issues waiting. SNS code is quite complex and not
> very thoroughly tested.
>
> BR,
>
> Jukka Zitting
>
Re: Same name siblings
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Feb 8, 2008 5:48 PM, David Nuescheler <da...@day.com> wrote:
> I think a feature that would address the "I have a bag of objects
> and I just want to persist them without thinking of a 'name' for
> each" usecase, would definitely be great. Maybe this could
> be the introduction of an addNode() without a childnode name.
Good idea! We could also allow "*" as a wildcard child node name in
the existing addNode() signatures.
> > WDYT, is SNS worth the effort, or should we consider dropping it?
> I don't think that it is problematic to have some features that are not
> optimized.
I think the issue runs deeper than just performance. We have at least
one open issue, JCR-435, and given the fact that we guide people away
from SNS at the first sings of trouble I wouldn't be surprised if
there were other issues waiting. SNS code is quite complex and not
very thoroughly tested.
BR,
Jukka Zitting
Re: Same name siblings
Posted by David Nuescheler <da...@day.com>.
Hi Jukka,
thanks a lot for bringing up the point.
> Support for same name siblings is troublesome and currently the best
> practice is to avoid them if possible. In many cases the default
> response when we see people having problems with SNS is to tell them
> not to use the feature.
I think one of the problems that I see is that people tend to use
SNS for anonymous collections without a sort order.
Which should be a very lightweight operation, and unfortunately
choosing SNS intuitively for that is probably just the most unstable
and heavyweight construct someone could choose in JCR.
I have not seen a lot of real justified use cases for SNS.
On the other hand I would really like to give people a means to
work with large anonymous unordered collections.
I think a feature that would address the "I have a bag of objects
and I just want to persist them without thinking of a 'name' for
each" usecase, would definitely be great. Maybe this could
be the introduction of an addNode() without a childnode name.
> I think that's lame. We should either treat SNS as a first-class
> feature that we just haven't been able to make work yet, or explicitly
> deprecate it and plan to drop or at least seriously limit the feature
> as far as is permitted by the JCR standard.
> The current status where SNS is kind of supported but "you should not
> use it!" is IMHO not sustainable in the long run.
> WDYT, is SNS worth the effort, or should we consider dropping it?
I don't think that it is problematic to have some features that are not
optimized. For example in most databases DELETE operations are slow
and people are referred to use TRUNCATE functions instead.
I think people are using SNS for the wrong reasons.
regards,
david
Re: Same name siblings
Posted by Marcel Reutegger <ma...@gmx.net>.
Jukka Zitting wrote:
> [...] or should we consider dropping it?
do we really have a choice? Since Jackrabbit acts as the basis for the JSR 283
reference implementation we cannot just drop it, can we?
regards
marcel
Re: Same name siblings
Posted by Stefan Guggisberg <st...@gmail.com>.
On Thu, Feb 14, 2008 at 11:40 AM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
>
> On Mon, Feb 11, 2008 at 11:33 AM, Martijn Hendriks <ma...@gx.nl> wrote:
> > I would say that SNS is worth the effort because dropping support completely
> > will give a serious migration issue for users that have deployed repositories that
> > use SNS and want to stay close to the newest Jackrabbit version.
>
> Agreed. Based on the comments in this thread I think we need to keep
> supporting SNS.
>
>
> > I am not into the technical details of the SNS support: what is exactly causing
> > problems and what would be needed to fix it?
>
> The main concerns are indexing (JCR-392) and versioning (JCR-43,
> JCR-435). Quite often we also see other issues related to SNS, see for
> example JCR-1167.
>
> I believe the technical issues could mostly (there are some tricky
> corner case semantics) be resolved, but currently we're not putting
> too much priority on such issues as evidenced by three of our four
> oldest known issues being about same name siblings.
i don't fully agree. i'd say that the main reason is that there's currenlty not
a lot of enthusiasm for tackling tricky versioning related issues ;).
such issues
being related to SNS is IMO just a coincidence.
> One reason for
> this is our basic response "same name siblings should be avoided"
> (JCR-392).
while i agree with the statement in general i think that the issue comment
is inappropriate.
>
> I don't think such approach is viable in the long term, so IMHO we
> need to decide whether using SNS is OK or not. If it's OK (as seems to
> be the message of this thread) then we need to start treating SNS
> issues more seriously and prioritize them higher than we do at the
> moment.
+1
cheers
stefan
>
> We can debate about and come up with guidelines on how to best use SNS
> where needed and where SNS is best avoided, but a "don't use SNS"
> response to SNS bug reports is IMHO not valid.
>
> BR,
>
> Jukka Zitting
>
Re: Same name siblings
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, Feb 11, 2008 at 11:33 AM, Martijn Hendriks <ma...@gx.nl> wrote:
> I would say that SNS is worth the effort because dropping support completely
> will give a serious migration issue for users that have deployed repositories that
> use SNS and want to stay close to the newest Jackrabbit version.
Agreed. Based on the comments in this thread I think we need to keep
supporting SNS.
> I am not into the technical details of the SNS support: what is exactly causing
> problems and what would be needed to fix it?
The main concerns are indexing (JCR-392) and versioning (JCR-43,
JCR-435). Quite often we also see other issues related to SNS, see for
example JCR-1167.
I believe the technical issues could mostly (there are some tricky
corner case semantics) be resolved, but currently we're not putting
too much priority on such issues as evidenced by three of our four
oldest known issues being about same name siblings. One reason for
this is our basic response "same name siblings should be avoided"
(JCR-392).
I don't think such approach is viable in the long term, so IMHO we
need to decide whether using SNS is OK or not. If it's OK (as seems to
be the message of this thread) then we need to start treating SNS
issues more seriously and prioritize them higher than we do at the
moment.
We can debate about and come up with guidelines on how to best use SNS
where needed and where SNS is best avoided, but a "don't use SNS"
response to SNS bug reports is IMHO not valid.
BR,
Jukka Zitting
RE: Same name siblings
Posted by Martijn Hendriks <ma...@gx.nl>.
Hi Jukka,
I would say that SNS is worth the effort because dropping support completely will give a serious migration issue for users that have deployed repositories that use SNS and want to stay close to the newest Jackrabbit version. You mention that the feature could also be limited as far as permitted by the JCR standard. What does that exactly mean wrt backwards compatability?
I am not into the technical details of the SNS support: what is exactly causing problems and what would be needed to fix it?
Best regards,
Martijn Hendriks
-----Original Message-----
From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
Sent: Friday, February 08, 2008 4:23 PM
To: dev@jackrabbit.apache.org
Subject: Same name siblings
Hi,
Support for same name siblings is troublesome and currently the best
practice is to avoid them if possible. In many cases the default
response when we see people having problems with SNS is to tell them
not to use the feature.
I think that's lame. We should either treat SNS as a first-class
feature that we just haven't been able to make work yet, or explicitly
deprecate it and plan to drop or at least seriously limit the feature
as far as is permitted by the JCR standard.
The current status where SNS is kind of supported but "you should not
use it!" is IMHO not sustainable in the long run.
WDYT, is SNS worth the effort, or should we consider dropping it?
BR,
Jukka Zitting
Re: Same name siblings
Posted by Alex Lukin <lu...@stu.cn.ua>.
Friday 08 February 2008 17:44:41 Thomas Mueller написав:
> Hi,
>
> I would drop it with migration path. Example:
>
> "
> Converting old repositories or xml with same name siblings will convert the
> composed name to literal names, that means: two nodes 'test' are converted
> to 'test[1]' and 'test[2]'; removing 'test[1] will not rename 'test[2]' to
> 'test[1]'.
+1
XML import requires SNS support so it can not be droped.
This idea sounds very resonable but what about XML export? Thus we have to restrict use of that kind of path names and all such nodes with indexes at the end
will be interpeted as SNS.
Another bad thing that new nodes must be added after last number used, even if that node already deleted. We want reliable paths I think.
So we must keep this info somewhere and delete it after last SNS with the name is deleted.
--
SY, Alex Lukin
RIPE NIC HDL: LEXA1-RIPE
Re: Same name siblings
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
I would drop it with migration path. Example:
"
Converting old repositories or xml with same name siblings will convert the
composed name to literal names, that means: two nodes 'test' are converted
to 'test[1]' and 'test[2]'; removing 'test[1] will not rename 'test[2]' to
'test[1]'.
"
Regards,
Thomas
On Feb 8, 2008 4:23 PM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> Support for same name siblings is troublesome and currently the best
> practice is to avoid them if possible. In many cases the default
> response when we see people having problems with SNS is to tell them
> not to use the feature.
>
> I think that's lame. We should either treat SNS as a first-class
> feature that we just haven't been able to make work yet, or explicitly
> deprecate it and plan to drop or at least seriously limit the feature
> as far as is permitted by the JCR standard.
>
> The current status where SNS is kind of supported but "you should not
> use it!" is IMHO not sustainable in the long run.
>
> WDYT, is SNS worth the effort, or should we consider dropping it?
>
> BR,
>
> Jukka Zitting
>
Re: Same name siblings
Posted by Tobias Bocanegra <to...@day.com>.
in this case you need a multivalue property. eg:
world.setProperty("message", new String[]{"Hello, World!", "Hello"});
On 2/10/08, vijay makija <vi...@yahoo.com> wrote:
> Hi Jukka ,
>
> I want to add two properties to single node with same
> name. But when I try to do so, new property overrides
> older property.
> As in example below, on setting message 2nd time first
> value is overidden.
> Node hello = root.addNode("hello");
> Node world = hello.addNode("world");
> world.setProperty("message", "Hello, World!");
> world.setProperty("message", "Hello");
>
> Is there anyway I can add both properties?
>
> Thanks in advance,
> Regards,
> Vijay Makhija
>
> --- Jukka Zitting <ju...@gmail.com> wrote:
>
> > Hi,
> >
> > Support for same name siblings is troublesome and
> > currently the best
> > practice is to avoid them if possible. In many cases
> > the default
> > response when we see people having problems with SNS
> > is to tell them
> > not to use the feature.
> >
> > I think that's lame. We should either treat SNS as a
> > first-class
> > feature that we just haven't been able to make work
> > yet, or explicitly
> > deprecate it and plan to drop or at least seriously
> > limit the feature
> > as far as is permitted by the JCR standard.
> >
> > The current status where SNS is kind of supported
> > but "you should not
> > use it!" is IMHO not sustainable in the long run.
> >
> > WDYT, is SNS worth the effort, or should we consider
> > dropping it?
> >
> > BR,
> >
> > Jukka Zitting
> >
>
>
>
> ____________________________________________________________________________________
> Never miss a thing. Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: Same name siblings
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
world.setProperty("message", "Hello, World!");
> world.setProperty("message", "Hello");
> Is there anyway I can add both properties?
No. The JCR specification only supportd same name node siblings are
supported. As in XML: you can't define two attributes with the same name:
<p id="hello" id="world" />
This is illegal. Same name node siblings are supported:
<p /><p />
Regards.
Thomas
Re: Same name siblings
Posted by vijay makija <vi...@yahoo.com>.
Hi Jukka ,
I want to add two properties to single node with same
name. But when I try to do so, new property overrides
older property.
As in example below, on setting message 2nd time first
value is overidden.
Node hello = root.addNode("hello");
Node world = hello.addNode("world");
world.setProperty("message", "Hello, World!");
world.setProperty("message", "Hello");
Is there anyway I can add both properties?
Thanks in advance,
Regards,
Vijay Makhija
--- Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> Support for same name siblings is troublesome and
> currently the best
> practice is to avoid them if possible. In many cases
> the default
> response when we see people having problems with SNS
> is to tell them
> not to use the feature.
>
> I think that's lame. We should either treat SNS as a
> first-class
> feature that we just haven't been able to make work
> yet, or explicitly
> deprecate it and plan to drop or at least seriously
> limit the feature
> as far as is permitted by the JCR standard.
>
> The current status where SNS is kind of supported
> but "you should not
> use it!" is IMHO not sustainable in the long run.
>
> WDYT, is SNS worth the effort, or should we consider
> dropping it?
>
> BR,
>
> Jukka Zitting
>
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs