Hi Peeter,
as discussed offline:
Peeter Piegaze wrote:
Except, shouldn't
//*[jcr:primaryType='X']
return a table with 1) A node iterator with every node of *declared* type X
2) A table with:
a) a row for each node of *declared* type X (that is, same as the iterator)
b) a column for each property *declared or inherited* in type X plus
the special pseudo-property column jcr:path.
2b) this would mix aspects of the select clause with those of property constraints. the columns for the result table should be governed by the column specifier (select clause in SQL, property selection in xpath) or the type constraint of the query (from clause in SQL, element node test in xpath).
With those basic rules the jcr:primaryType expression is just a predicate like any other, but allows to further restrict the nodes in the result set to a declared type.
The type constraint should therefore respect declared and inherited types. Which gives full flexibility to select nodes of a whole type hierarchy or just nodes of a declared type.
If that is true then
SELECT * FROM nt:base WHERE jcr:primaryType='X'
is not the equivalent, because it would produce a table with columns only for the properties declared in nt:base (jcr:primaryType,
jcr:mixinTypes) plus jcr:path.
Yes, based on the rule that when the column specifier selects all properties, the result table will consist of declared properties of the type specified in the type constraint. In this case nt:base.
so the correct SQL equivalent would be
SELECT * FROM X WHERE jcr:primaryType='X'
imo, this statement: SELECT * FROM X WHERE jcr:primaryType='X' is mapped to: //element(*, 'X')[EMAIL PROTECTED]:primaryType = 'X']
and gives you a result table with all declared properties of type X and nodes that have a declared type X (no nodes of subtypes).
whereas: SELECT * FROM X is mapped to: //element(*, 'X')
will return nodes of type X and also nodes of subtypes of X. the result table contains columns for the properties declared in X.
The current implementation of jackrabbit always returns nodes for the whole type hierarchy. This will eventually change when we move to the next revision of the spec.
regards marcel
