Bug #34327
exec_INSERTmultipleRows doesn't check for alternative handlers
| Status: | Resolved | Start date: | 2012-02-27 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assignee: | - | % Done: | 100% |
|
| Category: | - | |||
| Target version: | - | |||
| TYPO3 Version: | Tags: | |||
| Votes: | 0 |
Description
I spotted this issue while using the DbBackend of the CachingFramework, wich uses exec_INSERTmultipleRows to add tags to the tags table. When routing the tags table to another handler wich is also "native" it won't use the alternative handler for the tags table.
This happens because the function does not fetch the handler key for the current table and just calls the parent function if the type is "native".
A patch is attached to this issue. I will try to commit a patch in gerrit for review.
Related issues
| related to DBAL - Bug #48220: exec_INSERTmultipleRows insert double Rows | New | 2013-05-15 |
Associated revisions
[BUGFIX] exec_INSERTmultipleRows doesn't check alternative handlers
The function just passes the function call to it's parents insert
function when the type of the current handler is "native".
When using an alternative handler than "_DEFAULT" for a table, wich
connection is also "native", it will directly forward the call without
respecting my mapping for the table to another handler.
Similar to the other methods, this is solved by first fetching
the handler for the current table and then feeding the created
SQL string to mysql_query on given handler link.
The patch additionaly fixes db errors in 6.1 after mysqli switch.
Change-Id: I0c984b355916a99603ed72f0606e173608e4de81
Fixes: #34327
Releases: 6.1, 6.0, 4.7, 4.5
Reviewed-on: https://review.typo3.org/9272
Reviewed-by: Xavier Perseguers
Tested-by: Xavier Perseguers
Reviewed-by: Christian Kuhn
Tested-by: Christian Kuhn
[BUGFIX] exec_INSERTmultipleRows doesn't check alternative handlers
The function just passes the function call to it's parents insert
function when the type of the current handler is "native".
When using an alternative handler than "_DEFAULT" for a table, wich
connection is also "native", it will directly forward the call without
respecting my mapping for the table to another handler.
Similar to the other methods, this is solved by first fetching
the handler for the current table and then feeding the created
SQL string to mysql_query on given handler link.
The patch additionaly fixes db errors in 6.1 after mysqli switch.
Change-Id: I0c984b355916a99603ed72f0606e173608e4de81
Fixes: #34327
Releases: 6.1, 6.0, 4.7, 4.5
Reviewed-on: https://review.typo3.org/19758
Reviewed-by: Christian Kuhn
Tested-by: Christian Kuhn
[BUGFIX] exec_INSERTmultipleRows doesn't check alternative handlers
The function just passes the function call to it's parents insert
function when the type of the current handler is "native".
When using an alternative handler than "_DEFAULT" for a table, wich
connection is also "native", it will directly forward the call without
respecting my mapping for the table to another handler.
Similar to the other methods, this is solved by first fetching
the handler for the current table and then feeding the created
SQL string to mysql_query on given handler link.
The patch additionaly fixes db errors in 6.1 after mysqli switch.
Change-Id: I0c984b355916a99603ed72f0606e173608e4de81
Fixes: #34327
Releases: 6.1, 6.0, 4.7, 4.5
Reviewed-on: https://review.typo3.org/19759
Reviewed-by: Christian Kuhn
Tested-by: Christian Kuhn
[BUGFIX] exec_INSERTmultipleRows doesn't check alternative handlers
The function just passes the function call to it's parents insert
function when the type of the current handler is "native".
When using an alternative handler than "_DEFAULT" for a table, wich
connection is also "native", it will directly forward the call without
respecting my mapping for the table to another handler.
Similar to the other methods, this is solved by first fetching
the handler for the current table and then feeding the created
SQL string to mysql_query on given handler link.
The patch additionaly fixes db errors in 6.1 after mysqli switch.
Change-Id: I0c984b355916a99603ed72f0606e173608e4de81
Fixes: #34327
Releases: 6.1, 6.0, 4.7, 4.5
Reviewed-on: https://review.typo3.org/19760
Reviewed-by: Christian Kuhn
Tested-by: Christian Kuhn
History
Updated by Leon Dietsch about 1 year ago
- File patch.diff added
I forgot to add the patch. To resolve the issue I fetch the handler for the current table and check if the handlerKey is _DEFAULT, additionally to the check for handler type being 'native'.
Updated by Gerrit Code Review about 1 year ago
Patch set 1 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9272
Updated by Gerrit Code Review 3 months ago
Patch set 2 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/9272
Updated by Gerrit Code Review about 1 month ago
Patch set 3 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/9272
Updated by Gerrit Code Review about 1 month ago
Patch set 1 for branch dbal_6-0 has been pushed to the review server.
It is available at https://review.typo3.org/19758
Updated by Gerrit Code Review about 1 month ago
Patch set 1 for branch dbal_4-7 has been pushed to the review server.
It is available at https://review.typo3.org/19759
Updated by Gerrit Code Review about 1 month ago
Patch set 1 for branch DBAL_1-2 has been pushed to the review server.
It is available at https://review.typo3.org/19760
Updated by Christian Kuhn about 1 month ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
Applied in changeset 6494493f00e5b5388b00fe52946b235bd4934099.