Doctrine 1
  1. Doctrine 1
  2. DC-453

Joined records stated as dirty (whereas they are not modified)

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.2.1
    • Fix Version/s: None
    • Component/s: Record
    • Labels:
      None

      Description

      When you retrieve records like this:

      (Here I have Labels, that have Albums)

      $lab = Doctrine::getTable('Label')->createQuery('lab')
      ->leftJoin('lab.Albums alb')
      ->select('lab.id, alb.id')
      ->where('lab.id = ?', 1)
      ->fetchOne();

      $lab->state() is STATE_PROXY : it's ok, properties are not all loaded from the DB and the object is not modified

      BUT $lab->Albums[0]->state() is STATE_DIRTY : why ? the object is not modified...

      This causes real problems, because this way, joined objects unloaded properties are corrupted : it really behaves like they all are "null", and that's all. Their real values are never loaded from the DB.

        Activity

        Hide
        Benoît Guchet added a comment -

        No way to correct that ?

        Show
        Benoît Guchet added a comment - No way to correct that ?
        Hide
        Jonathan H. Wage added a comment -

        Can you provide a test case? are you sure it is dirty or you had the object instance prior to the query and it was dirty there?

        Show
        Jonathan H. Wage added a comment - Can you provide a test case? are you sure it is dirty or you had the object instance prior to the query and it was dirty there?
        Hide
        Benoît Guchet added a comment -

        Actually the given sample code is written to be a test case (Label/Albums can be any other basic Parent/Children relation).
        You retrieve an object, join a child relation, selects only some fields from the children => those children are Dirty.

        Yes I'm sure it is dirty, the Album object does not exist before that, the script does nothing else than this query. The object was born dirty, so to speak.

        Show
        Benoît Guchet added a comment - Actually the given sample code is written to be a test case (Label/Albums can be any other basic Parent/Children relation). You retrieve an object, join a child relation, selects only some fields from the children => those children are Dirty. Yes I'm sure it is dirty, the Album object does not exist before that, the script does nothing else than this query. The object was born dirty, so to speak.
        Hide
        Jonathan H. Wage added a comment -

        Sorry, I meant a Doctrine unit test case. Not just some pasted code in the issue.

        Show
        Jonathan H. Wage added a comment - Sorry, I meant a Doctrine unit test case. Not just some pasted code in the issue.
        Hide
        Michał Strzelecki added a comment -

        I have the same problem, but I have a deeper relation. The clue of it is that, that in Albums[0] is setting id of relation with lab.id (cause of that change STATE_DIRTY is set), and after that operation getModiefied method return array with one element
        array(
        id => lab.id
        )

        The bug is that, that in releted object after hydration setting releted id changing state of record -> it is wrong behavior, becaus nothing changed -> record has releted id with value, which is exactly the same as in DB.

        Show
        Michał Strzelecki added a comment - I have the same problem, but I have a deeper relation. The clue of it is that, that in Albums [0] is setting id of relation with lab.id (cause of that change STATE_DIRTY is set), and after that operation getModiefied method return array with one element array( id => lab.id ) The bug is that, that in releted object after hydration setting releted id changing state of record -> it is wrong behavior, becaus nothing changed -> record has releted id with value, which is exactly the same as in DB.

          People

          • Assignee:
            Jonathan H. Wage
            Reporter:
            Benoît Guchet
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: