DDC-132: Subclass' columns missing from cached ClassMetadata::$resultColumnNames #1934

Closed
doctrinebot opened this Issue Nov 9, 2009 · 9 comments

1 participant

@doctrinebot

Jira issue originally created by user reinier.kip:

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.

@doctrinebot

Comment created by romanb:

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?

@doctrinebot

Comment created by reinier.kip:

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.

@doctrinebot

Comment created by reinier.kip:

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.

@doctrinebot

Comment created by romanb:

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.

@doctrinebot

Comment created by @jwage:

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

@doctrinebot

Comment created by romanb:

Scheduled for ALPHA4 as this may need some restructuring.

@doctrinebot

Comment created by romanb:

This should be fixed now in trunk.

@doctrinebot

Issue was closed with resolution "Fixed"

@doctrinebot doctrinebot added this to the 2.0-ALPHA4 milestone Dec 6, 2015
@doctrinebot doctrinebot closed this Dec 6, 2015
@doctrinebot doctrinebot added the Bug label Dec 7, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment