Feature #16089

writeMM deletion trouble

Added by Nikolas Hagelstein about 15 years ago. Updated over 9 years ago.

Should have
Database API (Doctrine DBAL)
Target version:
Start date:
Due date:
% Done:


Estimated time:
PHP Version:
Sprint Focus:


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)

Related issues

Related to TYPO3 Core - Bug #16518: MM relations should be editable from both sides of the relationClosedSebastian Kurfuerst2006-09-01


Updated by Thomas Hempel about 15 years ago

This also occurs with Version 3.8.1


Updated by Nikolas Hagelstein about 15 years ago

this a temporary fix to writeMM:

if ($GLOBALS['writeMM']['deleted'][$tableName]!=1) {
//deletion code here


Updated by Ingmar Schlecht over 14 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 14 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 14 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 9 years ago

  • Status changed from Needs Feedback to Closed
  • Target version deleted (0)
  • PHP Version deleted (4)

Too old.

Also available in: Atom PDF