Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-1390

Lazy loading does not work for the relationships of an entity instance, whose class inherits from another entity class

    Details

    • Type: Bug Bug
    • Status: In Progress
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.1.1
    • Fix Version/s: None
    • Component/s: ORM
    • Security Level: All
    • Labels:
      None
    • Environment:
      Debian Linux 6.0, MySQL 5.0.51a

      Description

      Lazy loading does not work for the relationships of an instance of an entity, whose class inherits from another entity class.

      Assume there are two entity classes, A and B, where A inherits from B.

      Now let $a be an instance of A, e. g. the result of "SELECT a FROM \A WHERE a.id = 1".

      Outputting $a will confirm it is a valid instance of a proxy object inheriting from A.

      Assume that the database row corresponding to $a contains a non-null foreign key that actually links to an existing row in another table, corresponding to another entity instance of a different class.

      Now, $a->someRelationship will always returns null in this scenario. I assume this is unintended behaviour, because clearly, the other entity should be lazily loaded on accessing it, and there is a value in the database.

      The fetch annotation attribute on that relationship has not been explicitly set, so I assume it is set to the default value, which, according to the docs, should be "lazy".

      The loading only fails when accessing the relationships of an entity instance, whose class inherits from another entity class. For entity instances, whose classes do not inherit from another entity class, lazy loading of their relationships works as expected.

      I had a look at the proxy objects and verified that they are present and override the __get method with an implementation containing a call to the load() method. Still, the loading won't work for some reason.

      This could be related to Bug DDC-1389 (http://www.doctrine-project.org/jira/browse/DDC-1389) which also happens exclusively in an inheritance scenario. Maybe the current implementation of inheritance is generally wrong or incomplete.

      1. CommissionNoteCreatorResult.php
        0.9 kB
        Daniel Alvarez Arribas
      2. ConsumerInvoiceExporterResult.php
        0.3 kB
        Daniel Alvarez Arribas
      3. DataObject.php
        1 kB
        Daniel Alvarez Arribas
      4. DataVersion.php
        1 kB
        Daniel Alvarez Arribas
      5. DDC1390Test.php
        2 kB
        Benjamin Eberlei
      6. InvoiceCreatorResult.php
        0.8 kB
        Daniel Alvarez Arribas
      7. Result.php
        2 kB
        Daniel Alvarez Arribas
      8. Run.php
        2 kB
        Daniel Alvarez Arribas

        Activity

        Hide
        Benjamin Eberlei added a comment -

        Did this get fixed with the correction of your data?

        Show
        Benjamin Eberlei added a comment - Did this get fixed with the correction of your data?
        Hide
        Daniel Alvarez Arribas added a comment -

        No it did not. This issue is completely unrelated to the other one.

        For this, I have manually implemented workarounds, fetching the associations using DQL queries. Lazy loading in the inheritance scenario above still would not work.

        Show
        Daniel Alvarez Arribas added a comment - No it did not. This issue is completely unrelated to the other one. For this, I have manually implemented workarounds, fetching the associations using DQL queries. Lazy loading in the inheritance scenario above still would not work.
        Hide
        Benjamin Eberlei added a comment -

        So A is an entity in a hierachy A -> B, and "someRelationship" is a field on A or on B towards an Entity C that is in an inheritance hierachy or not?

        Could you post parts of the mappings (entity docblock and the relationship)?

        Show
        Benjamin Eberlei added a comment - So A is an entity in a hierachy A -> B, and "someRelationship" is a field on A or on B towards an Entity C that is in an inheritance hierachy or not? Could you post parts of the mappings (entity docblock and the relationship)?
        Hide
        Daniel Alvarez Arribas added a comment -

        Hey, thanks for taking care of this.

        I attached the entities involved in the szenario to this issue.

        I had problems lazy loading entities through the following associations:

        Run.invoiceCreatorResult
        Run.commissionNoteCreatorResult
        Run.consumerInvoiceExporterResult

        as well as

        InvoiceCreatorResult.dataVersion
        CommissionNoteCreatorResult.dataVersion
        ConsumerInvoiceExporterResult.dataVersion

        In this scenario, InvoiceCreatorResult, CommissionNoteCreatorResult and ConsumerInvoiceExporterResult all inherit from Result, which in turn inherits from a mapped superclass DataObject. Run and DataVersion inherit from DataObject directly.

        The associations where lazy loading does not work are associations both to and from the entity classes InvoiceCreatorResult, CommissionNoteCreatorResult and ConsumerInvoiceExporterResult.

        Show
        Daniel Alvarez Arribas added a comment - Hey, thanks for taking care of this. I attached the entities involved in the szenario to this issue. I had problems lazy loading entities through the following associations: Run.invoiceCreatorResult Run.commissionNoteCreatorResult Run.consumerInvoiceExporterResult as well as InvoiceCreatorResult.dataVersion CommissionNoteCreatorResult.dataVersion ConsumerInvoiceExporterResult.dataVersion In this scenario, InvoiceCreatorResult, CommissionNoteCreatorResult and ConsumerInvoiceExporterResult all inherit from Result, which in turn inherits from a mapped superclass DataObject. Run and DataVersion inherit from DataObject directly. The associations where lazy loading does not work are associations both to and from the entity classes InvoiceCreatorResult, CommissionNoteCreatorResult and ConsumerInvoiceExporterResult.
        Hide
        Benjamin Eberlei added a comment -

        Now let $a be an instance of A, e. g. the result of "SELECT a FROM \A WHERE a.id = 1".

        Outputting $a will confirm it is a valid instance of a proxy object inheriting from A.

        Just a short Q on understanding: Why is $a a proxy of A if you select it explicitly?

        Show
        Benjamin Eberlei added a comment - Now let $a be an instance of A, e. g. the result of "SELECT a FROM \A WHERE a.id = 1". Outputting $a will confirm it is a valid instance of a proxy object inheriting from A. Just a short Q on understanding: Why is $a a proxy of A if you select it explicitly?
        Hide
        Benjamin Eberlei added a comment -

        This a working test-case with a model that i believe resembles yours exactly.

        I also put your models into another test and ran schema validation on them, which works out without problems.

        From the workflow with proxies, maybe DDC-1452 might be related to your issue?

        Show
        Benjamin Eberlei added a comment - This a working test-case with a model that i believe resembles yours exactly. I also put your models into another test and ran schema validation on them, which works out without problems. From the workflow with proxies, maybe DDC-1452 might be related to your issue?
        Hide
        Daniel Alvarez Arribas added a comment -

        Regarding the proxy question, I just ment the query to be an example to further illustrate the type of $a. It was redundant and unnecessary though and probably misleading. Sorry for that. I did not select anything in the actual scenario. $a is merely some object of type A. No queries are involved.

        Show
        Daniel Alvarez Arribas added a comment - Regarding the proxy question, I just ment the query to be an example to further illustrate the type of $a. It was redundant and unnecessary though and probably misleading. Sorry for that. I did not select anything in the actual scenario. $a is merely some object of type A. No queries are involved.
        Hide
        Daniel Alvarez Arribas added a comment -

        Have you been able to make the tests fail with the original data provided?

        If not, I could set up a test case and post it.

        Show
        Daniel Alvarez Arribas added a comment - Have you been able to make the tests fail with the original data provided? If not, I could set up a test case and post it.
        Hide
        Benjamin Eberlei added a comment -

        No i only checked the validity of mappings with the original data. If you could setup a testcase that would be really great.

        Show
        Benjamin Eberlei added a comment - No i only checked the validity of mappings with the original data. If you could setup a testcase that would be really great.
        Hide
        Daniel Alvarez Arribas added a comment -

        I will set up a test case and upload it. I'll see if I can do it one of the next evenings.

        Show
        Daniel Alvarez Arribas added a comment - I will set up a test case and upload it. I'll see if I can do it one of the next evenings.
        Hide
        Benjamin Eberlei added a comment -

        I tried again, also extended DDC-1390, but it was impossible for me to reproduce this. I ran this against master, 2.1.x and 2.1.1 specifically.

        Show
        Benjamin Eberlei added a comment - I tried again, also extended DDC-1390 , but it was impossible for me to reproduce this. I ran this against master, 2.1.x and 2.1.1 specifically.
        Hide
        Daniel Alvarez Arribas added a comment - - edited

        Sorry, I got swamped with work. Now I am working on this dedicatedly, testing against the latest release. Will let you know once I have a testcase.

        Show
        Daniel Alvarez Arribas added a comment - - edited Sorry, I got swamped with work. Now I am working on this dedicatedly, testing against the latest release. Will let you know once I have a testcase.
        Hide
        Benjamin Eberlei added a comment -

        Good to hear, thanks for the persistent work on this.

        Show
        Benjamin Eberlei added a comment - Good to hear, thanks for the persistent work on this.

          People

          • Assignee:
            Benjamin Eberlei
            Reporter:
            Daniel Alvarez Arribas
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: