6.6.3.3 Property Constraint

A query may specify further constraints on the result nodes by way of property constraints.

XPath: In XPath a predicate that tests attributes on the last location step forms the property constraint expression. Predicates on any other location step are optional.

SQL: In SQL the WHERE clause forms the constraint expression.

Examples:

In order to ensure mutual translatability between XPath and SQL we only require support for the XPath general comparison operators (=, !=, <, <=, >, >=). In SQL the semantics of these operators must be the same as they are for XPath. The only difference is that in XPath the not-equal operator is !=, while in SQL it is <>.

The term “general comparison” comes from XPath terminology. The significance of requiring support for XPath general comparison, and their equivalents in SQL, lies in the way that these operators behave with multi-value properties. See 6.6.4.10 Searching Multi-value Properties for details.

Additionally, support for jcr:like() (LIKE in SQL) and jcr:contains (CONTAINS in SQL) is required (though the range of this requirement is qualified below).

Since not all property types can be meaningfully compared using all operators the following describes the minimal set of comparison support required for each property type:

STRING: =, != (<>), <, <=, >, >=, jcr:like()(LIKE)

LONG: =, != (<>), <, <=, >, >=

DOUBLE: =, != (<>), <, <=, >, >=

DATE: =, != (<>), <, <=, >, >=

NAME: =, != (<>)

PATH: =, != (<>), (additionally, in SQL, LIKE is used against the jcr:path pseudo-property to define path constraints, see 6.6.3.4 Path Constraint)

REFERENCE: =, != (<>)

BOOLEAN: =, != (<>)

BINARY: (none)

The jcr:like function in XPath corresponds to the LIKE operator in SQL. See 6.6.5.1 jcr:like Function and 8.5.4.4 LIKE.

Support for the jcr:contains() (CONTAINS() in SQL) function is not required for any property types in particular. It is however required to work at the node level. In that case it applies to those properties of the node for which the implementation maintains an index. Which properties those are is an implementation issue. See 6.6.5.2 jcr:contains Function and 8.5.4.5 CONTAINS.

Support for comparing jcr:score in a SQL WHERE clause or jcr:score(...) in a XPath predicate is not required.

In XPath support is only required for comparisons of the form <property><op><literalvalue> and <literalvalue><op><property>. For example, support for [@p = "hello"] and ["hello" = @p] (and so forth for each operator) is required. Support for [@p = @q] (and so forth for each operator) is not required.

Examples: