Details

    • Type: Sub-task Sub-task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.2.3
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
      PHP 5.3 / symfony 1.4.9

      Description

      Sorry for the lengthy explanation, couldn't make it more straight forward:

      I have a model which is similiar to a nestet set but the tree structure needs to overlap:

      For Model A, every Object A1 can have multiple descendant objects A2 and in turn can be a descendant of multiple objects A0.

      Since I saw no way to do this with Nested-Set Relations (or Equal-Nested-Sets) I have set up my Model like this:

      modules:
      columns: ..<do not matter>
      relations:
      Children:
      class: modules
      refClass: modules_required
      Parents:
      class: modules
      refClass: modules_required

      modules_required:
      columns: <do not matter here, just 2 foreign key columns>
      relations:
      Children:
      Parents:

      I needed to specify the Relations on both tables, to use onDelete/onUpdate CASCADE rules. Generated Models look fine, just as intended.
      (Every Class has many Children and has many Parents...)

      Now the strange part:
      When I update an object of modules (say id=18), Doctrine issues the following queries:
      DELETE FROM modules_required WHERE (required_id = ? AND module_id IN (?, ?, ?, ?, ?)) - (18, 25, 26, 32, 34, 35)
      // where 25 to 35 are CHILDREN of 18
      UPDATE modules_required SET required_id = ? WHERE module_id = ? AND required_id = ? - (25, 25, 10)
      UPDATE modules_required SET required_id = ? WHERE module_id = ? AND required_id = ? - (26, 26, 10)
      UPDATE modules_required SET required_id = ? WHERE module_id = ? AND required_id = ? - (32, 32, 10)
      UPDATE modules_required SET required_id = ? WHERE module_id = ? AND required_id = ? - (34, 34, 10)
      UPDATE modules_required SET required_id = ? WHERE module_id = ? AND required_id = ? - (35, 35, 10)
      UPDATE modules_required SET required_id = ? WHERE module_id = ? AND required_id = ? - (25, 25, 12)
      //where 10 and 12 are PARENTS of 18
      and somewhen, Doctrine encounters an MySQL ERROR because of the previous update marathon:
      SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '25-25' for key 'PRIMARY'

      The point is:
      1. why is Doctrine trying to create self-referencing relations, and
      2. why is it touching the relation at all, when i only did change some text fields in the object?

      Is there a better way to solve my problem?

        Activity

        Hide
        Daniel Reiche added a comment -

        forgot to add something: I have done a debug run, to see why these queries are created, when there was no data modified that related to these tables:

        Doctrine seems to handle my structure internally as a Nested-Set, although I have not specified an actAs: NestedSet or relations: equal: true statement in the model definition.
        Is there a way to prevent symfony from misinterpreting this?

        This is not a nested set, as each object can have virtually any other object either as parent or as a child, and additionaly, parent relations can span multiple tree-levels:
        Object 2 is parent of Object 3 and 6
        Object 3 is parent of Object 4 and 5
        Object 4 is parent of Object 6

        results in: Object 6 has parents 2 and 4 (where 4 has parent 3 and 3 has parent 2 in turn)

        This spanning relations seems to cause the guessed nested set to fail.

        I simply wanted to create an m:n Relation using a Reference table and the fact that both m and n are of the same class should not consider doctrine.

        Show
        Daniel Reiche added a comment - forgot to add something: I have done a debug run, to see why these queries are created, when there was no data modified that related to these tables: Doctrine seems to handle my structure internally as a Nested-Set, although I have not specified an actAs: NestedSet or relations: equal: true statement in the model definition. Is there a way to prevent symfony from misinterpreting this? This is not a nested set, as each object can have virtually any other object either as parent or as a child, and additionaly, parent relations can span multiple tree-levels: Object 2 is parent of Object 3 and 6 Object 3 is parent of Object 4 and 5 Object 4 is parent of Object 6 results in: Object 6 has parents 2 and 4 (where 4 has parent 3 and 3 has parent 2 in turn) This spanning relations seems to cause the guessed nested set to fail. I simply wanted to create an m:n Relation using a Reference table and the fact that both m and n are of the same class should not consider doctrine.
        Hide
        Daniel Reiche added a comment -

        related to #DC-329:
        seems to be the same general problem as described there. Only in DC 1.2.3, doctrine tries to delete every child-relation for some unknown reason.

        also the h2aEqualable mentioned there does not work, because it does not prevent symfony from issueing the delete queries. It prevents only the UPDATE-Queries, and thus circumvents the MySQL-Error.

        Nevertheless, data is still corrupted after object save, thus not useable in production.

        Show
        Daniel Reiche added a comment - related to # DC-329 : seems to be the same general problem as described there. Only in DC 1.2.3, doctrine tries to delete every child-relation for some unknown reason. also the h2aEqualable mentioned there does not work, because it does not prevent symfony from issueing the delete queries. It prevents only the UPDATE-Queries, and thus circumvents the MySQL-Error. Nevertheless, data is still corrupted after object save, thus not useable in production.

          People

          • Assignee:
            Jonathan H. Wage
            Reporter:
            Daniel Reiche
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: