DDC-3308: Cross platform support for DQL "WHERE ... IN" with multiple fields/columns #4087

Open
opened 2026-01-22 14:34:58 +01:00 by admin · 3 comments
Owner

Originally created by @doctrinebot on GitHub (Sep 13, 2014).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user markus.woessner:

DQL does not support "WHERE ... IN" statements which refer to more than one field.

Example: While
... WHERE e.id IN (1, 2) ...
is valid DQL
... WHERE (e.id, e.name) IN ((1, "amy"), (2, "fred")) ...
is not.

This was discussed some years ago here https://groups.google.com/forum/#!msg/doctrine-user/bE9RfiF4ZGk/vaiEvsX5_rwJ and it appears that it is not SQL-99. Sqlite does not support it, MySQL does.

As http://sqlfiddle.com/#!7/6169b/1 shows it is not a big deal to transform such a query into an equal query which prevents the usage of "WHERE ... IN" constraints at all. I guess the case "pair(a,b) is not unique" can be safely ignored if redundant pairs are skipped on temp table insertion.

Originally created by @doctrinebot on GitHub (Sep 13, 2014). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user markus.woessner: DQL does not support "WHERE ... IN" statements which refer to more than one field. Example: While `... WHERE e.id IN (1, 2) ...` is valid DQL `... WHERE (e.id, e.name) IN ((1, "amy"), (2, "fred")) ...` is not. This was discussed some years ago here https://groups.google.com/forum/#!msg/doctrine-user/bE9RfiF4ZGk/vaiEvsX5_rwJ and it appears that it is not SQL-99. Sqlite does not support it, MySQL does. As http://sqlfiddle.com/#!7/6169b/1 shows it is not a big deal to transform such a query into an equal query which prevents the usage of "WHERE ... IN" constraints at all. I guess the case "_pair(a,b) is not unique_" can be safely ignored if redundant pairs are skipped on temp table insertion.
admin added the New Feature label 2026-01-22 14:34:58 +01:00
Author
Owner

@doctrinebot commented on GitHub (Sep 14, 2014):

Comment created by @ocramius:

This looks everything but trivial to me, especially considering that it introduces usage of UNION, which we also do not support because of portability rules.

@doctrinebot commented on GitHub (Sep 14, 2014): Comment created by @ocramius: This looks everything but trivial to me, especially considering that it introduces usage of `UNION`, which we also do not support because of portability rules.
Author
Owner

@doctrinebot commented on GitHub (Sep 14, 2014):

Comment created by markus.woessner:

As far as I understand the UNION statement would only be needed when doing an "inline table" approach.

Isn't it a usual technique in Doctrine "AST to SQL output walking" to write temp tables?

@doctrinebot commented on GitHub (Sep 14, 2014): Comment created by markus.woessner: As far as I understand the UNION statement would only be needed when doing an "inline table" approach. Isn't it a usual technique in Doctrine "AST to SQL output walking" to write temp tables?
Author
Owner

@doctrinebot commented on GitHub (Sep 14, 2014):

Comment created by @ocramius:

Yes, we use subqueries in a lot of places, but the paginator walkers are already a real mess from a maintenance PoV, so I don't think we want to go down that route.

@doctrinebot commented on GitHub (Sep 14, 2014): Comment created by @ocramius: Yes, we use subqueries in a lot of places, but the paginator walkers are already a real mess from a maintenance PoV, so I don't think we want to go down that route.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#4087