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

New Issue

admin · 2026-01-22T12:29:13+01:00

admin commented

2026-01-22 12:29:13 +01:00

Originally created by @doctrinebot on GitHub (Nov 9, 2009).

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.

Originally created by @doctrinebot on GitHub (Nov 9, 2009). 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.

admin added the Bug label 2026-01-22 12:29:13 +01:00

admin closed this issue

2026-01-22 12:29:15 +01:00

admin commented

2026-01-22 12:29:15 +01:00

@doctrinebot commented on GitHub (Nov 9, 2009):

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 commented on GitHub (Nov 9, 2009): 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?

admin commented

2026-01-22 12:29:15 +01:00

@doctrinebot commented on GitHub (Nov 10, 2009):

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 commented on GitHub (Nov 10, 2009): 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.

admin commented

2026-01-22 12:29:16 +01:00

@doctrinebot commented on GitHub (Nov 10, 2009):

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 commented on GitHub (Nov 10, 2009): 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.

admin commented

2026-01-22 12:29:17 +01:00

@doctrinebot commented on GitHub (Nov 10, 2009):

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 commented on GitHub (Nov 10, 2009): 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.

admin commented

2026-01-22 12:29:18 +01:00

@doctrinebot commented on GitHub (Nov 11, 2009):

Comment created by @jwage:

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

@doctrinebot commented on GitHub (Nov 11, 2009): Comment created by @jwage: Here is a patch which fixes the issue but through doing this roman and I realized another issue.

admin commented

2026-01-22 12:29:19 +01:00

@doctrinebot commented on GitHub (Nov 11, 2009):

Comment created by romanb:

Scheduled for ALPHA4 as this may need some restructuring.

@doctrinebot commented on GitHub (Nov 11, 2009): Comment created by romanb: Scheduled for ALPHA4 as this may need some restructuring.

admin commented

2026-01-22 12:29:19 +01:00

@doctrinebot commented on GitHub (Dec 9, 2009):

Comment created by romanb:

This should be fixed now in trunk.

@doctrinebot commented on GitHub (Dec 9, 2009): Comment created by romanb: This should be fixed now in trunk.

admin commented

2026-01-22 12:29:19 +01:00

@doctrinebot commented on GitHub (Dec 9, 2009):

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (Dec 9, 2009): Issue was closed with resolution "Fixed"

admin commented

2026-01-22 12:29:19 +01:00

@doctrinebot commented on GitHub (Dec 13, 2015):

Imported 1 attachments from Jira into https://gist.github.com/bb26bf1d944b4e23b1d6

10155_patch.diff

@doctrinebot commented on GitHub (Dec 13, 2015): Imported 1 attachments from Jira into https://gist.github.com/bb26bf1d944b4e23b1d6 - [10155_patch.diff](https://gist.github.com/bb26bf1d944b4e23b1d6#file-10155_patch-diff)

admin referenced this issue

2026-01-22 15:56:56 +01:00

[PR #165] [MERGED] Update lib/Doctrine/ORM/Query/Expr/Base.php #7800

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#165