jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: TCK / SQLPathTest.testChildAxisRoot
Date Thu, 28 Jun 2012 13:27:18 GMT
Hi,

Thanks a lot! I see the current Jackrabbit 2.x works as required by the specification. I was
worried there is a bug. Well, the specification is a bit strange because the SQL expression
('/' LIKE '/%') should clearly return true. But that's OK, there is no rule that a specification
can't be strange.

Unless I misread that part of the specification, a compliant specification *may* return the
root node for this test, right? In that case I will change the test case slightly, to allow
it (but not to require it).

Regards,
Thomas


From: Randall Hauch <rhauch@gmail.com<mailto:rhauch@gmail.com>>
Reply-To: "dev@jackrabbit.apache.org<mailto:dev@jackrabbit.apache.org>" <dev@jackrabbit.apache.org<mailto:dev@jackrabbit.apache.org>>
To: "dev@jackrabbit.apache.org<mailto:dev@jackrabbit.apache.org>" <dev@jackrabbit.apache.org<mailto:dev@jackrabbit.apache.org>>
Subject: Re: TCK / SQLPathTest.testChildAxisRoot

Surprisingly, the test appears to be correct as written: the root node should NOT be included
in the results.

To see why, we have to look at Section 6.6.3.4 ("Path Constraint") in the JSR-170 specification,
since we're talking about JCR's original SQL language. In particular, the "Child node path
constraint" example shows the JCR SQL and XPath queries that find the children of the "/some/nodes"
node as:

SELECT * FROM my:type
WHERE jcr:path LIKE '/some[%]/nodes[%]/%'
AND NOT jcr:path LIKE '/some[%]/nodes[%]/%/%'

and

/jcr:root/some/nodes/element(*, my:type)

These queries are the same pattern of query issued in the test, and basically show the combination
of LIKE and NOT LIKE that are required to find the children of a node.

Other parts of the specification outline why this example works the way it does. Section 6.6.5.1
("jcr:like function") defines the semantics of the wildcard characters as generally used within
LIKE predicates (and "jcr:like" in XPath):

"As in SQL, the character ‘%’ represents any string of zero or more
characters, and the character ‘_’ (underscore) represents any
single character."

while Section 8.5.2.2 ("Pseudo-property jcr:path") specifies the semantics "jcr:path" pseudo
column and narrows the semantics of using LIKE with "jcr:path" in the second-to-last bullet
point:

"Predicates in the WHERE clause that test jcr:path are only required to
support the operators =, <> and LIKE. In the case of LIKE predicates,
support is only required for tests using the % wildcard character as a
match for a whole path segment (the part between two / characters)
or within index brackets.…"

Because the '%' matches only a whole path segment, the "/%" literal only matches paths that
have at least one path segment, which means that it matches all descendants of the root node.

I hope this helps.

Best regards,

Randall

Hi,

The test case SQLPathTest.testChildAxisRoot runs the following SQL-1 query:


    SELECT * FROM nt:base WHERE jcr:path LIKE '/%' AND NOT jcr:path LIKE '/%/%'


It expected the result to be


    /jcr:system, /testroot, /testdata


Shouldn't "/" (the root node) also be part of the result? The '%' is supposed to match zero
or more characters.


Regards,

Thomas



Mime
View raw message