Skip to content

Loading…

DDC-1390: Lazy loading does not work for the relationships of an entity instance, whose class inherits from another entity class #2011

Closed
doctrinebot opened this Issue · 16 comments

2 participants

@doctrinebot

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](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

Comment created by @beberlei:

Did this get fixed with the correction of your data?

@doctrinebot

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

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

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

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

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

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

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

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

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

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

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

Comment created by @beberlei:

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

@doctrinebot

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

Issue was closed with resolution "Cannot Reproduce"

@beberlei beberlei was assigned by doctrinebot
@doctrinebot doctrinebot closed this
@doctrinebot doctrinebot added the Bug label
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.