[Resource] Fixed issue with mapping inheritance and mapped superclass (Gedmo)

[pamil]

Q	A
Bug fix?	yes
New feature?	no
BC breaks?	no
Deprecations?	no
Fixed tickets	#1363, #3621, #1438, #478
License	MIT

Probably fixes all bugs related to Gedmo DoctrineExtensions and mapping inheritance :)

[pjedrzejewski]

Thanks Kamil!

[inssein]

@pamil sweet! I will definitely be checking this out once I get home.

From taking a quick look, I can't seem to make sense of it easily. How does loading of the metadata when using cache get fixed by changing the priority of the event?

[pamil]

@inssein SyliusResourceBundle does some really weird things with mapping (allowing mapped superclasses to have relationships and ids, etc.). As far as I know, it happened only while metadata cache was enabled and when the initial class metadata cache was created not in main application, but in some command (I'm not 100% sure here).

Anyway, it resulted in the loadClassMetadata listeners being in the order like that:

• SluggableListener
• TreeListener
• LoadORMResourcesListener
• TimestampableListener
• SoftDeletableListener

This is the reason we had those problems with slugs and trees, but not with much more widely used timestampable and softdeletable behaviours.

If you take a look at Gedmo's ExtensionMetadataFactory::getExtensionMetadata($meta), you'll see this code at the beginning:

if ($meta->isMappedSuperclass) {
    return; // ignore mappedSuperclasses for now
}

So our mapped superclasses were transformed into entities just after the first two Gedmo listeners were called and their metadata was empty at that moment :)

[inssein]

@pamil For me (#3621) Timestampable also wasn't working.

[pamil]

@inssein It depends on how your application looked like, with ResourceBundle listeners guaranteed to be on top, it should work everywhere :)