Bug #67172
AdoDB error on editing a page
| Status: | Resolved | Start date: | 2015-05-27 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assigned To: | - | % Done: | 100% |
|
| Category: | Database API | Spent time: | - | |
| Target version: | - | |||
| TYPO3 Version: | 7 | Is Regression: | No | |
| PHP Version: | 5.5 | Sprint Focus: | ||
| Complexity: |
Description
In dev master using postgresql (with dbal and adodb), when clicking on Edit page properties in BE I get this error:
#1421053336: ADOdb could not run this query: SELECT "uid" FROM "sys_category" WHERE FIND_IN_SET('0', "parent") != 0 OR "parent" = ''
This error is thrown by a "if (!is_object($sqlResult))" test ($sqlResult is a huge amount of "object(ADORecordSet_postgres8)" whereas it should be, I presume, one single object).
I can't locate where this $sqlResult comes from.
Related issues
Associated revisions
[BUGFIX] dbal: Cast field to CHAR for FIND_IN_SET()
Implement explicit casting of fields to a character representation.
Most DBMS are stricter in regard to data type checking and emit an
error when trying to use FIND_IN_SET() on non-text field types.
On the DBAL side of things the DBMS specifics are used to define that
an explicit cast is required for FIND_IN_SET() so that a query including
the CAST statement gets generated.
A PostgreSQL Specific has been added to enable the explicit casting in
conjuction with DBAL. To avoid checking repeatedly if a DBMS has defined
specific requirements a NullSpecific has been implemented that gets used
as a default.
In the DatabaseTreeDataProvider the listFieldQuery() function has been
changed to use an explicit CAST instead of relying on the implicit
cast done by MySQL when comparing it to an empty string.
The SqlParser has been extended with the support for CAST.
Resolves: #67155
Resolves: #67172
Resolves: #46271
Releases: master, 6.2
Change-Id: Ic77d1700e0fb4e3723c90b34e131dafb456038e0
Reviewed-on: http://review.typo3.org/39779
Reviewed-by: Andreas Fernandez <typo3@scripting-base.de>
Tested-by: Andreas Fernandez <typo3@scripting-base.de>
Reviewed-by: Markus Klein <markus.klein@typo3.org>
Tested-by: Markus Klein <markus.klein@typo3.org>
[BUGFIX] dbal: Cast field to CHAR for FIND_IN_SET()
Implement explicit casting of fields to a character representation.
Most DBMS are stricter in regard to data type checking and emit an
error when trying to use FIND_IN_SET() on non-text field types.
On the DBAL side of things the DBMS specifics are used to define that
an explicit cast is required for FIND_IN_SET() so that a query including
the CAST statement gets generated.
A PostgreSQL Specific has been added to enable the explicit casting in
conjuction with DBAL. To avoid checking repeatedly if a DBMS has defined
specific requirements a NullSpecific has been implemented that gets used
as a default.
In the DatabaseTreeDataProvider the listFieldQuery() function has been
changed to use an explicit CAST instead of relying on the implicit
cast done by MySQL when comparing it to an empty string.
The SqlParser has been extended with the support for CAST.
Resolves: #67155
Resolves: #67172
Resolves: #46271
Releases: master, 6.2
Change-Id: Ic77d1700e0fb4e3723c90b34e131dafb456038e0
Reviewed-on: http://review.typo3.org/39779
Reviewed-by: Andreas Fernandez <typo3@scripting-base.de>
Tested-by: Andreas Fernandez <typo3@scripting-base.de>
Reviewed-by: Markus Klein <markus.klein@typo3.org>
Tested-by: Markus Klein <markus.klein@typo3.org>
Reviewed-on: http://review.typo3.org/41842
History
#1 Updated by alexis nicolas 2 months ago
Additional information:
Script mod.php?M=record_edit&moduleToken=8122495a9af184a42f55f1a33fe13fd6012a2294&edit[pages][112]=edit&returnUrl=/TYPO3.CMS/typo3/mod.php?M=Dweb_layout/moduleToken=D0fb5f69ddc295f9dcc6263262f151a9c54613b9e&id=112 returns a 500 error whereas I'm on a localhost.
PostrgreSQL log returns:
function find_in_set(unknown, bigint) doesn't exist No function matches given name and argument type You must add explicit type cast
#2 Updated by alexis nicolas 2 months ago
- % Done changed from 0 to 100
Solution given in #46271 works here.
#3 Updated by Gerrit Code Review 2 months ago
- Status changed from New 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 http://review.typo3.org/39779
#4 Updated by Gerrit Code Review 2 months ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/39779
#5 Updated by Gerrit Code Review about 1 month ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/39779
#6 Updated by Gerrit Code Review about 1 month ago
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/39779
#7 Updated by Gerrit Code Review about 1 month ago
Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/39779
#8 Updated by Gerrit Code Review about 1 month ago
Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/39779
#9 Updated by Gerrit Code Review 18 days ago
Patch set 7 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/39779
#10 Updated by Morton Jonuschat 12 days ago
- Status changed from Under Review to Resolved
Applied in changeset 14f04a6a526ce654c86e7e62bcf4cb09cfca6eb2.
#11 Updated by Gerrit Code Review 12 days ago
- Status changed from Resolved to Under Review
Patch set 1 for branch TYPO3_6-2 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/41842
#12 Updated by Morton Jonuschat 12 days ago
- Status changed from Under Review to Resolved
Applied in changeset a780e46ad709bcf5df9253182c620cec8c748bc4.