Hmm, I see... Thank you for your explanation, I misunderstand the definition of "is null" concept.
I just thought of a workaround, I will search for a certain constant property that will be included in all subnodes. This is not the most graceful way to test existence of a node from a query, but it should do the trick. Thanks Frank Le 2010-01-20 à 6:38 PM, Alexander Klimetschek a écrit : > 2010/1/18 François Cassistat <[email protected]>: >> I can't make a minimal example with the exactly the same problem, but there >> seems to have something wrong with this "is null"/"is not null" operation : >> >> Here's a simple repository : >> /a >> /a/@jcr:primaryType=nt:unstructured >> /a/c >> /a/c/@test=value >> /a/c/@jcr:primaryType=nt:unstructured >> /a/c/d >> /a/c/d/@jcr:primaryType=nt:unstructured >> >> workspace.getQueryManager().createQuery("//*...@test='value' and not(d/e)]", >> Query.XPATH).execute().getNodes().nextNode(); >>> returns /a/c (which is normal) >> >> workspace.getQueryManager().createQuery("//*...@test='value' and >> not(d/e/@f)]", Query.XPATH).execute().getNodes().nextNode(); >>> fails, no results (which is wrong, i think) > > The existence/non-existence check only works for properties (same for > NULL/IS NULL in sql). The spec does not require support for relative > paths to properties in those predicates. > > Using a subpath like "d/e/@f" will not work reliably, only direct > check like "@f". I think it would be nice to fix that so that it works > consistently, but I guess it's quite difficult to scale that, as the > lucene index used only indexes properties, but not paths. But I am not > so sure about that. > >> workspace.getQueryManager().createQuery("//*...@test='value' and d/e]", >> Query.XPATH).execute().getNodes().nextNode(); >>> returns /a/c (which is wrong too, i think) > > Existence/non-existence does not work for nodes at all. > > Regards, > Alex > > -- > Alexander Klimetschek > [email protected]
