Might this be due to the bug you found and reported as MODE-1473? It's hard to tell whether that's the cause, without knowing more about the results and the other nodes. If not, please feel free to log an issue, posting as much information in the JIRA issue as you can.

It is definitely not the bug from MODE-1473 because I don't use this method but instantiate JcrEquiJoinCondition directly.

Actually it is difficult to describe the issue without the whole source code, but I'm going to provide it ASAP.

Nevertheless let me try.

I'm trying to write a method creating QueryObjectModel by means of javax.jcr.query.qom.QueryObjectModelFactory. As the master I use a JCR query made "manually". On the top of this topic you can see the output of statements.

I started with modeshape version 2.8.0.Final.

What I noticed that QOMF doesn't "like" square-brackets but it accepted my join condition:

Yes, it is pretty confusing. :-) You should not have to put the square brackets in the parameters to the factory methods, and you certainly shouldn't have to build the QOM query, obtain the statement, and execute the statement.

Can you provide a test case (or test cases) that demostrate the problem(s)? That would make it significantly easier to make sure we're correctly and thoroughly fixing the problem your seeing. The test case(s) can simply create an in-memory repository, build the queries and check the results. If it's easier to reuse your node types, then register them in the repository configuration; if not, then maybe try to duplicate with some built-in node types (but don't use residual property definitions).

You should not have to put the square brackets in the parameters to the factory methods, and you certainly shouldn't have to build the QOM query, obtain the statement, and execute the statement.

Yes, I know. As I wrote it's just a workaround, since QOM returns wrong result, but the same query but with square brackets does.

Randall Hauch wrote:

Can you provide a test case (or test cases) that demostrate the problem(s)? That would make it significantly easier to make sure we're correctly and thoroughly fixing the problem your seeing. The test case(s) can simply create an in-memory repository, build the queries and check the results. If it's easier to reuse your node types, then register them in the repository configuration; if not, then maybe try to duplicate with some built-in node types (but don't use residual property definitions).

When you do that, please log a new issue. We'll target it (and MODE-1473) for a 2.8.2.Final patch release, which is currently unscheduled but which we can probably schedule to release within a few weeks maximum.

JCR-JQOM -> SELECT * FROM test:test AS a INNER JOIN test:second AS second INNER JOIN test:owner AS owner ON second.owner = owner.jcr:uuid ON a.second = second.jcr:uuid WHERE owner.myAttribute = $owner_myAttribute
AQM -> SELECT * FROM test:test AS a INNER JOIN test:second AS second INNER JOIN test:owner AS owner ON second.owner = owner.jcr:uuid ON a.second = second.jcr:uuid WHERE owner.myAttribute = $owner_myAttribute

which is wrong. But the qom executes it without claiming.

But if I take its statement, insert quare brackets where required, create a normal query and try to execute; I tend generally to verify queries created by QOM this way, it I get an exception:

Exception in thread "main" javax.jcr.query.InvalidQueryException: The JCR-SQL2 query "SELECT a.* FROM [test:test] AS a INNER JOIN [test:second] AS second INNER JOIN [test:owner] AS owner ON second.owner = owner.[jcr:uuid] ON a.second = second.[jcr:uuid] WHERE owner.myAttribute = $owner_myAttribute" is not well-formed: Expecting "ON" but found "INNER" at line 1, column 69: t:second] AS second ===>> INNER JOIN [test:own

Back to my issue with the wrong type in QOM result let me write my assumption I got on debbuging: I have an impression that eather org.modeshape.graph.query.plan.CanonicalPlanner or org.modeshape.graph.query.plan.PlanNode whose selector sequence is wrong.

I just tried to extract the files from your attachment, and wasn't able to. Can you please create a bug in our JIRA for this issue, and attach the source code as a ZIP file to the issue? Even if it's not a bug, we need to track it in order for us to work on it.