Technically, the JCR 2.0 specification only requires that minimally only single-valued properties be supported in queries (see Section 6.7.1 of the specification). However, we do want that functionality to work, and there's already an open issue (MODE-1679)
you are absolutely right. It is always safer to follow a specification of a technology on developing an application. But it is also easy to drift into the vendor specific goodies if they fullfil the application requirements and fill the usability gaps, and finally if these goodies are provided by the other vendors too.
Thanks and kind regards,
I think the fix for MODE-1679 will correct this behavior so that you can query single- and multi-valued REFERENCE properties in the same way. For example, here's a query that would check for nodes with a 'foo:bar' property (with a multi-valued REFERENCE property definition) that points to a particular node:
SELECT [foo:bar] FROM [some:type]
WHERE [foo:bar] = '77295951-d72a-41b9-8700-26c64c7d0256'
Here's another query that uses a join to find nodes that reference other nodes:
SELECT typed.* FROM [notion:typed] AS typed
JOIN [mix:referenceable] AS target ON typed.[notion:multipleReferences] = target.[jcr:uuid]
WHERE PATH(target) = '/Other/NodeA'
And here's another query that uses a subquery to do the same thing:
SELECT [notion:multipleReferences] FROM [notion:typed]
WHERE [notion:multipleReferences] IN (
SELECT [jcr:uuid] FROM [mix:referenceable] AS node WHERE PATH(node) = '/Other/NodeA'
These queries all work correctly with the fix to the issue.
Thanks a lot Randall!