mirror of
https://github.com/doctrine/orm.git
synced 2026-03-24 06:52:09 +01:00
DDC-1390: Lazy loading does not work for the relationships of an entity instance, whose class inherits from another entity class #1742
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @doctrinebot on GitHub (Sep 22, 2011).
Originally assigned to: @beberlei on GitHub.
Jira issue originally created by user dalvarez:
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.
@doctrinebot commented on GitHub (Oct 31, 2011):
Comment created by @beberlei:
Did this get fixed with the correction of your data?
@doctrinebot commented on GitHub (Nov 1, 2011):
Comment created by dalvarez:
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.
@doctrinebot commented on GitHub (Nov 1, 2011):
Comment created by @beberlei:
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)?
@doctrinebot commented on GitHub (Nov 6, 2011):
Comment created by dalvarez:
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.
@doctrinebot commented on GitHub (Nov 18, 2011):
Comment created by @beberlei:
{quote}
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.
{quote}
Just a short Q on understanding: Why is $a a proxy of A if you select it explicitly?
@doctrinebot commented on GitHub (Nov 18, 2011):
Comment created by @beberlei:
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?
@doctrinebot commented on GitHub (Nov 18, 2011):
Comment created by dalvarez:
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.
@doctrinebot commented on GitHub (Nov 18, 2011):
Comment created by dalvarez:
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.
@doctrinebot commented on GitHub (Nov 18, 2011):
Comment created by @beberlei:
No i only checked the validity of mappings with the original data. If you could setup a testcase that would be really great.
@doctrinebot commented on GitHub (Nov 19, 2011):
Comment created by dalvarez:
I will set up a test case and upload it. I'll see if I can do it one of the next evenings.
@doctrinebot commented on GitHub (Dec 17, 2011):
Comment created by @beberlei:
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.
@doctrinebot commented on GitHub (Jan 5, 2013):
Comment created by dalvarez:
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.
@doctrinebot commented on GitHub (Jan 6, 2013):
Comment created by @beberlei:
Good to hear, thanks for the persistent work on this.
@doctrinebot commented on GitHub (May 27, 2015):
Comment created by dalvarez:
I have to admit I really goofed up on this one, sorry.
Right now I no longer have access the setup, since I am working on unrelated things.
Closing this for now as non-reproducible. If I should ever have another scenario at hand where the issue occurs, I will reopen the issue and provide you with a test case.
@doctrinebot commented on GitHub (May 27, 2015):
Issue was closed with resolution "Cannot Reproduce"
@doctrinebot commented on GitHub (Dec 13, 2015):
Imported 8 attachments from Jira into https://gist.github.com/50b8e24061f7718f07c9