You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Thomas Mueller <mu...@adobe.com> on 2012/06/28 12:50:48 UTC
TCK / SQLPathTest.testChildAxisRoot
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
Re: TCK / SQLPathTest.testChildAxisRoot
Posted by Randall Hauch <rh...@gmail.com>.
I would agree that a compliant implementation could return the root node for this test.
On Thursday, June 28, 2012 at 8:27 AM, Thomas Mueller wrote:
> 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
> >
>
Re: TCK / SQLPathTest.testChildAxisRoot
Posted by Thomas Mueller <mu...@adobe.com>.
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 <rh...@gmail.com>>
Reply-To: "dev@jackrabbit.apache.org<ma...@jackrabbit.apache.org>" <de...@jackrabbit.apache.org>>
To: "dev@jackrabbit.apache.org<ma...@jackrabbit.apache.org>" <de...@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
Re: TCK / SQLPathTest.testChildAxisRoot
Posted by Randall Hauch <rh...@gmail.com>.
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
>