You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by François Cassistat <f...@maya-systems.com> on 2010/01/15 17:14:22 UTC

Bug with XPath operation "IS NOT NULL" ?

In JSR-170 spec, for the XPath syntax :
my:title IS NOT NULL => @my:title
my:title IS NULL => not(@my:title)

On JackRabbit 2.0 beta 1 :

//*[@property1 = 'some value' and not(path/to/my/@property2)]
always returns no result, while :

//*[@property1 = 'some value' and path/to/my/@property2]
returns some results. Am I doing something wrong or it is a bug ?


Frank


Re: Bug with XPath operation "IS NOT NULL" ?

Posted by François Cassistat <f...@maya-systems.com>.
Hi,

Any workaround?
Should I file a bug report ?


Frank


Le 2010-01-18 à 10:44 AM, François Cassistat a écrit :

> 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)
> 
> workspace.getQueryManager().createQuery("//*[@test='value' and d/e]", Query.XPATH).execute().getNodes().nextNode();
>> returns /a/c (which is wrong too, i think)
> 
> 
> Frank
> 
> 
> 
> Le 2010-01-18 à 8:35 AM, Alexander Klimetschek a écrit :
> 
>> 2010/1/15 François Cassistat <f...@maya-systems.com>:
>>> On JackRabbit 2.0 beta 1 :
>>> 
>>> //*[@property1 = 'some value' and not(path/to/my/@property2)]
>>> always returns no result, while :
>>> 
>>> //*[@property1 = 'some value' and path/to/my/@property2]
>>> returns some results. Am I doing something wrong or it is a bug ?
>> 
>> What are the value(s) of @property2 in your content? If there is no
>> node that has @property1='some value' and _no_ @property2 set, the
>> results are to be expected.
>> 
>> Regards,
>> Alex
>> 
>> -- 
>> Alexander Klimetschek
>> alexander.klimetschek@day.com
> 


Re: Bug with XPath operation "IS NOT NULL" ?

Posted by François Cassistat <f...@maya-systems.com>.
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 <f...@maya-systems.com>:
>> 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
> alexander.klimetschek@day.com


Re: Bug with XPath operation "IS NOT NULL" ?

Posted by Alexander Klimetschek <ak...@day.com>.
2010/1/18 François Cassistat <f...@maya-systems.com>:
> 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
alexander.klimetschek@day.com

Re: Bug with XPath operation "IS NOT NULL" ?

Posted by François Cassistat <f...@maya-systems.com>.
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)

workspace.getQueryManager().createQuery("//*[@test='value' and d/e]", Query.XPATH).execute().getNodes().nextNode();
> returns /a/c (which is wrong too, i think)


Frank



Le 2010-01-18 à 8:35 AM, Alexander Klimetschek a écrit :

> 2010/1/15 François Cassistat <f...@maya-systems.com>:
>> On JackRabbit 2.0 beta 1 :
>> 
>> //*[@property1 = 'some value' and not(path/to/my/@property2)]
>> always returns no result, while :
>> 
>> //*[@property1 = 'some value' and path/to/my/@property2]
>> returns some results. Am I doing something wrong or it is a bug ?
> 
> What are the value(s) of @property2 in your content? If there is no
> node that has @property1='some value' and _no_ @property2 set, the
> results are to be expected.
> 
> Regards,
> Alex
> 
> -- 
> Alexander Klimetschek
> alexander.klimetschek@day.com


Re: Bug with XPath operation "IS NOT NULL" ?

Posted by Alexander Klimetschek <ak...@day.com>.
2010/1/15 François Cassistat <f...@maya-systems.com>:
> On JackRabbit 2.0 beta 1 :
>
> //*[@property1 = 'some value' and not(path/to/my/@property2)]
> always returns no result, while :
>
> //*[@property1 = 'some value' and path/to/my/@property2]
> returns some results. Am I doing something wrong or it is a bug ?

What are the value(s) of @property2 in your content? If there is no
node that has @property1='some value' and _no_ @property2 set, the
results are to be expected.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com