[DDC-132] Subclass' columns missing from cached ClassMetadata::$resultColumnNames Created: 09/Nov/09  Updated: 09/Dec/09  Resolved: 09/Dec/09

Status: Closed
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, ORM
Affects Version/s: 2.0-ALPHA3
Fix Version/s: 2.0-ALPHA4
Security Level: All

Type: Bug Priority: Critical
Reporter: Reinier Kip Assignee: Roman S. Borschel
Resolution: Fixed Votes: 0
Labels: None

Attachments: File patch.diff    

 Description   

I have a Customer with class table inheritance mapping and some fields, and a subclass called SuperCustomer with two fields: bool `isSuper` and string `extra`.

I found that when replacing the usual ArrayCache with a MemcacheCache, everything works fine on the first request, but notices occur on subsequent requests:

Notice: Undefined index: isSuper in X:\...\Doctrine\ORM\Persisters\StandardEntityPersister.php on line 577
Notice: Undefined index: extra in X:\...\Doctrine\ORM\Persisters\StandardEntityPersister.php on line 577

Inspection of ClassMetadata::$resultColumnNames on line 569 showed that the two fields `isSuper` and `extra` were (the only things) missing. The resulting object's `isSuper` and `extra` properties were empty.

I have yet to find the cause of this, but maybe you have an idea.



 Comments   
Comment by Roman S. Borschel [ 09/Nov/09 ]

This is indeed strange. My first guess was that the resultColumnNames get lost during serialization but the ClassMetadata#__sleep implementation seems to be correct in so far as it returns the resultColumnNames field as part of the fields to serialize.

Let me know as soon as you have more information.

Btw. Which metadata driver are you using? Annotations?

Comment by Reinier Kip [ 10/Nov/09 ]

> My first guess was that the resultColumnNames get lost during serialization
This would be really strange, as the columns of the parent class Customer are still there after unserialization, so only a part is lost during serialization. My first guess was that the metadata is cached before the metadata loading is finished.

> Which metadata driver are you using? Annotations?
I'm using a custom metadata driver. Caching is separated from the driver, so the driver couldn't have anything to do with this, right?

I'll try to find where it goes wrong and let you know.

Comment by Reinier Kip [ 10/Nov/09 ]

First request:

  • Customer metadata is loaded and cached to Customer$CLASSMETADATA. $resultColumnNames contains Customer's fields.
  • SuperCustomer metadata is loaded and cached to SuperCustomer$CLASSMETADATA. $resultColumnNames contains Customer's and SuperCustomer's fields.
  • I request an object of class Customer be loaded from the database, which is an instance of SuperCustomer.
  • StandardEntityPersister::_createEntity() is called to create the entity, and uses Customer metadata ALSO CONTAINING SuperCustomer's $resultColumnNames.

Second request:

  • Customer metadata is loaded from Customer$CLASSMETADATA. $resultColumnNames contains Customer's fields.
  • SuperCustomer metadata is loaded from SuperCustomer$CLASSMETADATA. $resultColumnNames contains Customer's and SuperCustomer's fields.
  • I request an object of class Customer be loaded from the database, which is an instance of SuperCustomer.
  • StandardEntityPersister::_createEntity() is called to create the entity, and uses Customer metadata NOT CONTAINING SuperCustomer's $resultColumnNames.

Thought: the Customer's metadata is somehow changed after caching to cope with Customer's subclasses as well, but these changes are not in the cache. I don't have enough knowledge of Doctrine's internals, but you probably have a pretty good idea where this could happen.

Comment by Roman S. Borschel [ 10/Nov/09 ]

Thanks for your detailed information. I think I know what the issue is now. May be non-trivial to fix. I will try to look into it as soon as I got some free time.

Comment by Jonathan H. Wage [ 11/Nov/09 ]

Here is a patch which fixes the issue but through doing this roman and I realized another issue.

Comment by Roman S. Borschel [ 11/Nov/09 ]

Scheduled for ALPHA4 as this may need some restructuring.

Comment by Roman S. Borschel [ 09/Dec/09 ]

This should be fixed now in trunk.

Generated at Sat Oct 25 04:35:44 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.