Bug #79388
closedExtbase converts IN expressions with empty values to 1<>1 in SQL silently
100%
Description
This leads to queries that look different to what is requested initially and hides mistakes of the developer where an empty value is passed to an IN statement, which would normally cause an SQL error.
The same issue applies to CONTAINS expressions.
This is even more a problem in CMS 7, where extbase query caching actually caches the resulting query. Hence, if the query is first constructed with an empty value, the query is stored in the cache with "1<>1" in the where clause and with no IN statement. Therefore any valid execution of the query will never result in the intended data set. In the case where the query is constructed correctly with the IN-part, any call with an empty value will result in an SQL error.
In production this bug looks like a random generator is mangling SQL statement and it is close to impossible for a normal user to get any glimpse of what is going on.
In the CMS 8 the situation is a bit more relaxed, as the query cache is gone. Yet it seems rather stupid to run a query where we know beforehand that a constraint is useless anyway.
We see no sane way to fix that in CMS 7, but we provide a patch which causes the query parser to throw an exception instead of silently converting the comparision to a 1<>1.
Updated by Gerrit Code Review almost 8 years ago
- Status changed from Accepted to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/51360
Updated by Markus Klein almost 8 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 56c20415636f6a28bd91e5fb4846ab81052578af.
Updated by Gerrit Code Review almost 8 years ago
- Status changed from Resolved to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/51363
Updated by Daniel Goerz almost 8 years ago
- Status changed from Under Review to Resolved
Applied in changeset 05670e4a35005a9ffe504cc88291cc72b2e713b5.
Updated by Riccardo De Contardi about 7 years ago
- Status changed from Resolved to Closed