Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Performing union prevents common table expressions from appearing in query. #798
SQLQuery query = query(); query.with(fooPathAlias, fooSubqueryExpression); query.union(barListSubQuery, bazListSubQuery); query.list();
The SQL to manifest does not contain the common table expression added on line 2 but instead has only the select statement for the union which, for obvious reasons, won't compile.
added a commit
Jun 10, 2014
referenced this issue
Jun 10, 2014
Apologies, the fact that the "close" button was available to me as the
My team have been using querydsl for a month or so and as we continue to
From looking at the API, I must assume that subqueries in the select clause
I can't see a method of (deliberately) performing a Cartesian join. In ANSI
FROM employee e INNER JOIN car c ON e.id = c.employee.id,
I was also looking to see if I could in some way manipulate the serialsed
Another thought that came to mind is the way select statements for unions
Thanks for all your hard work on querydsl, I'm very impressed with it so
Should be supported. Did you run into any walls?
What could construct_to_cartesian_join_to be? Do you miss join types?
Query flags are the way to do here:
Feel free to suggest syntactical improvements.
@Shredder121 is right, for typed instances it works fine. Do you have a dynamic query population use case?
Thanks @Shredder121, based on your example, I've got that cleaned up.
Apparently only my inexperience with the api and a lack of examples. In hindsight, this is very straightforwards. How did I miss this???
I was unaware of the "CROSS JOIN" type. Coming from a non-ANSI Oracle background, previously I would list a table in the FROM clause and simply not apply any join conditions or filtering.
Thanks, this is exactly what I am looking for.
Based on this conversation, I think it would be wise for me to get a few more api miles beneath my feet before passing further comment. My team and I are committed to using querydsl for all of our reporting needs, so as and when we do have any suggestions, we'll be sure to share them.
@timowest Thanks again for your quick response. Filling in these small gaps has really enhanced our use of the api.