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.
>
