Project

General

Profile

Actions

Bug #23980

open

Relations with MM_opposite_field don't update the relation count of opposite field

Added by Kevin Ulrich Moschallski over 13 years ago. Updated 7 months ago.

Status:
Accepted
Priority:
Could have
Assignee:
-
Category:
DataHandler aka TCEmain
Target version:
-
Start date:
2010-11-07
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.4
PHP Version:
5.3
Tags:
Complexity:
nightmare
Is Regression:
No
Sprint Focus:

Description

I use this config in TCA for symmetric relations between two tables:

Local side:

'config' => array(
'type' => 'group',
'internal_type' => 'db',
'allowed' => 'tx_specialoffersmvc_domain_model_item',
'foreign_table' => 'tx_specialoffersmvc_domain_model_item',
'MM_opposite_field' => 'portals',
'MM' => 'tx_specialoffersmvc_portal_item_mm',
'MM_match_fields' => array(
'tablenames' => 'tx_specialoffersmvc_domain_model_portal'
),
'size' => 5,
'maxitems' => 9999
)

Foreign side:

'config' => array(
'type' => 'group',
'internal_type' => 'db',
'allowed' => 'tx_specialoffersmvc_domain_model_portal',
'MM_match_fields' => array('tablenames' => 'tx_specialoffersmvc_domain_model_portal'),
'foreign_table' => 'tx_specialoffersmvc_domain_model_portal',
'foreign_field' => 'items',
'prepend_tname' => 1,
'size' => 5,
'maxitems' => 9999,
'MM' => 'tx_specialoffersmvc_portal_item_mm',
)

The realation works fine but the field values aren't updated correctly.

I found this in the mailing list:

http://lists.typo3.org/pipermail/typo3-dev/2010-February/038917.html

Franz Koch gave me the right posision to fix this. Unfortunately his approach with the TCEMain_postProc wasn't availible anymore on the pastbin page.

So i tried to fix it in the core. I'll append a patch for review. The patch is against TYPO3 4.4.4

(issue imported from #M16294)


Files

bug_16292.patch (4.91 KB) bug_16292.patch Administrator Admin, 2010-11-07 17:25
class.tx_elementshelpers_tcemain.php (4.41 KB) class.tx_elementshelpers_tcemain.php Administrator Admin, 2010-11-13 10:48

Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #66574: Relations of definitions using MM_opposite_field are missing in ReferenceIndexClosed2015-04-24

Actions
Actions #1

Updated by Franz Koch over 13 years ago

I attached my hook workaround so that it doesn't get lost again like on pastbin.

Actions #2

Updated by Nabil Saleh almost 12 years ago

  • Target version deleted (0)

This bug has great impact on extbase relationmapping too as extbase expects the "relation"-field for the mm relation to be !== null (see datamapper) and otherwise does not fetch related records. Also One might have a look at http://forge.typo3.org/issues/32549

Actions #3

Updated by Thomas Deinhamer almost 12 years ago

This also happens on 6.0.0-dev on PHP 5.4.3.

Nabil Saleh is also right about Extbase, which
won't find the relation and returns NULL/0 when
using a repository and/or a query object.

Actions #4

Updated by Thomas Deinhamer almost 12 years ago

If the record is edited from the local side (the field without the "opposite field" configuration),
the "count" seems to be set correctly and Extbase will find the record, so I think #32549
may be already fixed - mind: I'm using Extbase 6.0.0-dev with the new property mapper enabled.

Actions #5

Updated by Thomas Deinhamer over 11 years ago

Is there a chance to have this in 6.0?

Actions #6

Updated by Mathias Schreiber over 9 years ago

  • Description updated (diff)
  • Category set to DataHandler aka TCEmain
  • Target version set to 7.4 (Backend)
  • Is Regression set to No
Actions #7

Updated by Susanne Moog over 8 years ago

  • Target version changed from 7.4 (Backend) to 7.5
Actions #8

Updated by Benni Mack over 8 years ago

  • Target version changed from 7.5 to 7 LTS
Actions #9

Updated by Mathias Schreiber over 8 years ago

  • Target version deleted (7 LTS)
Actions #10

Updated by Oliver Hader over 6 years ago

  • Status changed from New to Accepted
  • Complexity set to nightmare
Actions #11

Updated by Oliver Hader over 6 years ago

  • Priority changed from Should have to Could have

sys_category is a very good and generic example. For instance adding a new category to e.g. pages.category field should as a result also update also sys_category records that a references in the MM table. Implementing this opposite look-up and update might really become a nightmare.

If the problem is Extbase only, I'd rather suggest to take the additional MM join on the database level.

Actions #12

Updated by Adrian Rudnik 7 months ago

I'm currently trying to index documents that are related through a common m:n relationship. As this is not triggered through the processmap thingies, what would be the best way to catch these kind of changes?

Actions

Also available in: Atom PDF