@mpdude please review

Unfortunately, provided solution doesn't work in our use case, same error: Syntax error

Unfortunately, provided solution doesn't work in our use case, same error: Syntax error

Can you give me more details, like which database system you’re using and when this happened?

I can confirm that it works here with MySQL, ORM v3.5.3.

Unfortunately, provided solution doesn't work in our use case, same error: Syntax error

Can you give me more details, like which database system you’re using and when this happened?

It looks like additional loop in expandParameters caused not resolved types in inferParameterTypes because giving one value - it returns types as array uuid_binary_ordered_time as string, while in older version it returns object typeOf UuidBinaryOrderedTimeType

it worked in doctrine/orm 2.20.6, and stopped working in doctrine/orm 2.20.7. Only one dependency updated.
we are using additionally ramsey/uuid-doctrine:1.8.2

It could be unrelated, I think it's working for you, because it's simple case, but Ramsey has convertToDatabaseValue and it passes binary string https://github.com/ramsey/uuid-doctrine/blob/1.8.2/src/UuidBinaryOrderedTimeType.php#L110 instead of type or uuid string format

Sorry for confusion, I retract all my comments, it looks like we had bugfix, which doesn't work anymore. But thanks for fixing things! ❤️

@elliotbruneel Thank you for working on this!

Two remarks, probably a matter of personal preference:

1. I'd prefer using 1=0 over IN (NULL). To me, that makes the intent more clear. I don't know if it would be better portable as well.

2. We could amend the \Doctrine\Tests\ORM\Persisters\BasicEntityPersisterTypeValueSqlTest::testSelectConditionStatementWithMultipleValuesContainingNull test where the logic in question has been covered before.

If you're looking for a suggestion, you may want to check https://github.com/doctrine/orm/compare/2.20.x...mpdude:doctrine2:fix-12190-regression?expand=1.

Just noticed that IN (NULL) was the SQL we generated before. So, obviously, it's sufficiently portable, at least nobody complained.

Just noticed that IN (NULL) was the SQL we generated before. So, obviously, it's sufficiently portable, at least nobody complained.

My first goal was indeed to keep original generated code. I have edited the logic as it's more clear

@mpdude as long as it is in a separate commit, which is the case, I'm satisfied.

Thanks @elliotbruneel !

@mpdude IN (NULL) is guaranteed to not match any rows. And IN (1=0) would match "falsy" (or real boolean false) values, depending on the DBMS.

Not IN(1=0), only 1=0

@mpdude

postgresql:

# SELECT * FROM unnest(ARRAY[true, false]) AS t(col) WHERE col IN (1=0);
 col 
-----
 f
(1 row)

# SELECT * FROM unnest(ARRAY[null, true, false]) AS t(col) WHERE col IN (null);
 col 
-----
(0 rows)

@mpdude oh I see now, the suggestion was not to have IN (...) operator at all, just 1=0 expression. Right, my fault.