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 <[email protected] (mailto:[email protected])>
> Reply-To: "[email protected] (mailto:[email protected])"
> <[email protected] (mailto:[email protected])>
> To: "[email protected] (mailto:[email protected])"
> <[email protected] (mailto:[email protected])>
> 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
> >
>
