RE: Use of "not" in xpath queries (1.4 snapshot / trunk)

[Ard Schrijvers <a....@hippo.nl>]

Hello,

I am crossposting to dev list because it is a development issue we might
want to discuss for the 1.4 release (because behavior of a query changed
a little)

> /jcr:root//element(*, MyNodeType)[not(@propertyA)]
> 
> After some testing, it seems that where propertyA is defined 
> on MyNodeType (in the .cnd file), then this query will now 
> not match nodes that do not have a value for propertyA. Where 
> propertyA is not a defined property for MyNodeType, nodes 
> will be matched. Previously (in 1.3.3), nodes that had the 
> property defined but did not have a value for that property 
> would be returned by the query (this is what I had expected 
> from the jsr-170 spec). Thanks in advance for any help,

So for 1.3.3 IIUC, when you queried for : give me all nodes where
property X does not exist, it would return documents which have the
property X, but where it is empty? IMO, it is not logical, then again,
unfortunate that the behavior would have changed. We did change the way
this query is executed (see JCR-1064). 

I see where the problem arises from, but I think it did not work
correctly before (though others might be better in judging this. I
think, it did not work correctly in 1.3.3, and you made use of something
which is not logical (returning nodes which have the property, where you
say that they shouldn't have it)) 

Which part of the jsr-170 spec are you referring to by the way?

Anyway, we changed the MatchAllQuery into a query that test for the
existence of a property in SET_PROPERTIES. Since your property is
present, with the not(@prop) it will not return your document. 

In 1.3.3, we used the MatchAllScorer for this, where the query term was
computed in 

String namedValue = FieldNames.createNamedValue(field, "");
TermEnum terms = reader.terms(new Term(FieldNames.PROPERTIES,
namedValue));

and in FieldNames :

public static String createNamedValue(String fieldName, String value) {
        return fieldName + '\uFFFF' + value;
}

I think, because of this '\uFFFF', you did not get a match for an empty
property before, where you do get a match now.

Anyway, IMO, it now works correct. WDOT?

-Ard

> 
> Dean.
> 

Re: Use of "not" in xpath queries (1.4 snapshot / trunk)

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

Hi,

On Jan 10, 2008 12:57 PM, Dean Jones <de...@gmail.com> wrote:
> I've narrowed down this change in behaviour a bit. In Jackrabbit 1.3,
> the 'not()' predicate would match multivalued properties that had an
> empty array as the value. In 1.4, not() no longer matches such
> properties. I would guess that 1.4 has the correct behaviour and that
> we were relying on the incorrect behaviour of 1.3.

Thanks for the analysis, I think you're right!

> Might be worth an entry in the release notes for 1.4.

Good point, I'll do that.

BR,

Jukka Zitting

Re: Use of "not" in xpath queries (1.4 snapshot / trunk)

[Dean Jones <de...@gmail.com>]

On Jan 9, 2008 2:52 PM, Ard Schrijvers <a....@hippo.nl> wrote:
>
> > I'm referring to Section 6.6.3.3. There is a table on p108
> > (I'm going from v1.0.1, March 2006) with the following SQL / XPATH
> > correspondence:
> >
> >   my:title IS NULL  <-> not(@my:title)
>
> Perhaps in sql your perception is the correct one, but in xpath it is
> not [not(@mytitle)] means that the attribute should be not present. attr
> mytitle="" is not the same as absent obviously. I am not sure wether the
> spec is ambiguous in this, perhaps somebody else might elaborate.
>

I've narrowed down this change in behaviour a bit. In Jackrabbit 1.3,
the 'not()' predicate would match multivalued properties that had an
empty array as the value. In 1.4, not() no longer matches such
properties. I would guess that 1.4 has the correct behaviour and that
we were relying on the incorrect behaviour of 1.3. Might be worth an
entry in the release notes for 1.4.

Best wishes,

Dean.

RE: Use of "not" in xpath queries (1.4 snapshot / trunk)

[Ard Schrijvers <a....@hippo.nl>]

> I'm referring to Section 6.6.3.3. There is a table on p108 
> (I'm going from v1.0.1, March 2006) with the following SQL / XPATH
> correspondence:
> 
>   my:title IS NULL  <-> not(@my:title)

Perhaps in sql your perception is the correct one, but in xpath it is
not [not(@mytitle)] means that the attribute should be not present. attr
mytitle="" is not the same as absent obviously. I am not sure wether the
spec is ambiguous in this, perhaps somebody else might elaborate. 

> 
> If this interpretation of the spec is not accurate, how do I 
> get the previous behaviour in v1.4? My initial thought is to 
> set the property value to null and then test for that, but 
> I'd like to be sure I'm doing things properly to protect 
> myself against future changes in behaviour :-)

I think we could quite easily change the new code to work like it did
before, but I would first like to know how it is supposed to work
according the spec. WDOT?

-Ard

> 
> Thanks,
> 
> Dean.
> 

Re: Use of "not" in xpath queries (1.4 snapshot / trunk)

[Dean Jones <de...@gmail.com>]

Hello Ard,

On Jan 9, 2008 1:14 PM, Ard Schrijvers <a....@hippo.nl> wrote:
> Hello,
>
> > /jcr:root//element(*, MyNodeType)[not(@propertyA)]
> >
>
> So for 1.3.3 IIUC, when you queried for : give me all nodes where
> property X does not exist, it would return documents which have the
> property X, but where it is empty? IMO, it is not logical, then again,
> unfortunate that the behavior would have changed. We did change the way
> this query is executed (see JCR-1064).
>
That's correct (these are multivalued properties, btw).

> I see where the problem arises from, but I think it did not work
> correctly before (though others might be better in judging this. I
> think, it did not work correctly in 1.3.3, and you made use of something
> which is not logical (returning nodes which have the property, where you
> say that they shouldn't have it))
>
> Which part of the jsr-170 spec are you referring to by the way?
>

I'm referring to Section 6.6.3.3. There is a table on p108 (I'm going
from v1.0.1, March 2006) with the following SQL / XPATH
correspondence:

  my:title IS NULL  <-> not(@my:title)

My interpretation of this was that it is equivalent to a query on a
SQL table that has a column "title" where the value of the column is
null. In JCR terms, I assumed that this equates to a node type with
the property defined, but with no value for that property.

If this interpretation of the spec is not accurate, how do I get the
previous behaviour in v1.4? My initial thought is to set the property
value to null and then test for that, but I'd like to be sure I'm
doing things properly to protect myself against future changes in
behaviour :-)

Thanks,

Dean.