Project

General

Profile

Actions

Bug #32549

closed

DataMapper returns empty array for MM relations on opposite field side because relation field is empty

Added by Klaus Bitto over 12 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Could have
Assignee:
-
Category:
-
Target version:
-
Start date:
2011-12-14
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

Given you have two models:

Apple

Banana

The two models are related with an MM table. Apple is local (with relation field Apple::$bananas),
Banana is foreign, using MM_opposite_field on Banana::$apples.

1) Add a Banana to an apple ( $someApple->addBanana($somebanana); )

2) In the database, Apple.bananas will now be 1. Banana.apples should be 1 but it will be '' (empty).

3) If you open your banana (=opposite/foreign side) in the BE list view, you will see the apple in the select field defined in the TCA, as MM_opposite_field is defined as Apple.bananas. This means that Core does NOT care about whether or not Banana.apples is empty or not.

4) If on the other hand you use extbase, and request $somebanana->getApples(), you will get an empty object storage. Why?

    protected function fetchRelatedEager(Tx_Extbase_DomainObject_DomainObjectInterface $parentObject, $propertyName, $fieldValue = '') {
        if ($fieldValue === '') return array();
        [...]
    }

This is broken.

a) Either, when updating an MM relation, the opposite field needs to be updated with the corresponding count as well (neither core nor extbase are doing that)
b) or when resolving the relation from the opposite field side (or possibly any side), there CANNOT be a check for if the field value is empty. (core can deal with that, extbase cannot)

When you want to check this bug, make sure that when you open your banana in the back end, not to save it. Core will update Banana.apples (=opposite field) if saved directly. It will merely NOT update Banana.apples if you save an apple. I hope I could make clear what I mean.

PS: Probably this guy's problem is related: http://lists.typo3.org/pipermail/typo3-dev/2010-February/038917.html although it only touches Core, not extbase (which are two different problems).

Actions #1

Updated by Klaus Bitto over 12 years ago

If you want a patch, here goes ;)

file: typo3/sysext/extbase/Classes/Persistence/Mapper/DataMapper.php

    /**
     * Fetches the related objects from the storage backend.
     *
     * @param Tx_Extbase_DomainObject_DomainObjectInterface $parentObject The object instance this proxy is part of
     * @param string $propertyName The name of the proxied property in it's parent
     * @param mixed $fieldValue The raw field value.
     * @param bool $performLanguageOverlay A flag indication if the related objects should be localized
     * @return void
     */
    protected function fetchRelatedEager(Tx_Extbase_DomainObject_DomainObjectInterface $parentObject, $propertyName, $fieldValue = '') {
-               if ($fieldValue === '') return array();
+//             if ($fieldValue === '') return array();
        $query = $this->getPreparedQuery($parentObject, $propertyName, $fieldValue);
        return $query->execute();
    }

Tested, works. :)

Actions #2

Updated by Xavier Perseguers about 12 years ago

  • Target version deleted (4.6.2)
Actions #3

Updated by Nabil Saleh almost 12 years ago

I cannot confirm the patch works problem seems to be in the thawProperties-method wich checks the column value against null before doing anything. That might be usefull for anything else except many to many relations, but if you keep the null value vor a collection field / Tx_Extbase_Persistence_ObjectStorage and you're trying to access it later on it's messy. Furthermore one cannot trust the relation field to contain the correct relation count as it's very likely to be wrong see http://forge.typo3.org/issues/23980 for more information.

Actions #4

Updated by Thomas Deinhamer almost 12 years ago

poke Any updates on this? Thanks! :)

Actions #5

Updated by Thomas Deinhamer almost 12 years ago

Probably already fixed? See #23980 for more information.

Actions #6

Updated by Thomas Deinhamer almost 12 years ago

Finding the objects seems to work with the
new property manager, but if you remove the
object via $repository->remove($object); the
record in the MM table gets deleted but the
"counters" of both tables will stay the same.

So after the removing of the objects, the
counter is not decreased in the "origin" objects.

Not sure if this is intended.

Actions #7

Updated by Alexander Schnitzler over 11 years ago

  • Category changed from Extbase: Generic Persistence to Extbase: New Persistence
Actions #8

Updated by Helmut Hummel over 11 years ago

  • Status changed from New to Needs Feedback
  • Priority changed from Must have to Could have

Klaus B wrote:

Given you have two models:

Can you please post the full TCA configuration of your example?

Actions #9

Updated by Alexander Schnitzler about 11 years ago

  • Target version set to Extbase 6.2
Actions #10

Updated by Anja Leichsenring almost 11 years ago

  • Target version changed from Extbase 6.2 to Extbase 6.3
Actions #11

Updated by Alexander Opitz over 9 years ago

  • Status changed from Needs Feedback to Closed
  • Target version deleted (Extbase 6.3)

No feedback within the last 90 days => closing this issue.

If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.

Actions #12

Updated by Michael Stucki about 9 years ago

  • Project changed from 534 to TYPO3 Core
  • Category deleted (Extbase: New Persistence)
  • TYPO3 Version set to 6.2
  • Is Regression set to No

Moved ticket on request of Frank Nägler

Actions

Also available in: Atom PDF