Feature #16089
closed
writeMM deletion trouble
0%
Description
assuming the following tca setup:
--------
"groups1" => Array (
"exclude" => 1,
"l10n_mode" => "exclude",
"label" => "LLL:EXT:test/locallang_db.php:tx_test_product.groups1",
"config" => Array (
"type" => "select",
"foreign_table" => "tx_test_product_group",
"foreign_table_where" => "and x=1 ORDER BY tx_test_product_group.uid",
"size" => 10,
"minitems" => 0,
"maxitems" => 100,
"MM" => "tx_test_product_prod_group_mm",
)
),
"groups2" => Array (
"exclude" => 1,
"l10n_mode" => "exclude",
"label" => "LLL:EXT:test/locallang_db.php:tx_test_product.groups2",
"config" => Array (
"type" => "select",
"foreign_table" => "tx_test_product_group",
"foreign_table_where" => "and x=2 ORDER BY tx_test_product_group.uid",
"size" => 10,
"minitems" => 0,
"maxitems" => 100,
"MM" => "tx_test_product_prod_group_mm",
)
),
--------
writeMM of class.t3lib_loaddbgroup.php would be called twice, so that only the groups2 would be saved because writeMM first deletes all relations. This will become a problem especially in common with e.g.dynaflex. I suggest to modify it to be aware of the "foreign_table_where" field. Withhin this context it may be also useful to integrate pid handling and bidirectional relations.
(issue imported from #M3347)
Updated by Thomas Hempel almost 18 years ago
This also occurs with Version 3.8.1
Updated by Nikolas Hagelstein almost 18 years ago
this a temporary fix to writeMM:
if ($GLOBALS['writeMM']['deleted'][$tableName]!=1) {
//deletion code here
$GLOBALS['writeMM']['deleted'][$tableName]=1;
}
Updated by Ingmar Schlecht over 17 years ago
This won't be fixed.
You need to use different MM-tables if you want to have two relations from table A pointing to table B, even if the foreign_table_where is different.
Updated by Nikolas Hagelstein over 17 years ago
Using different MM tables for connecting the same tables over and over again is quite ugly and unflexible and furthermore it disagrees to the concept of relational tables.
The way suggested by Igmar would result in one extra MM table for every matching criteria of the foreign table. Not that good.
Updated by Ingmar Schlecht over 17 years ago
You're right, using different MM tables for each matching criteria causes some overhead (i.e. more mm tables), yet it's the only supported one at the moment.
I leave this bug open as a feature request. Sponsoring welcome.
Updated by Dmitry Dulepov over 12 years ago
- Status changed from Needs Feedback to Closed
- Target version deleted (
0) - PHP Version deleted (
4)
Too old.