community_store
community_store copied to clipboard
Can't refresh doctrine entities, got discriminator map error
Some guys already reported in the past, but I got the same error, so raised the new issue.
Exception Occurred: /path/to/concrete/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/MappingException.php:679 Entity 'Concrete\Package\CommunityStore\Entity\Attribute\Key\StoreProductKey' has to be part of the discriminator map of 'Concrete\Core\Entity\Attribute\Key\Key' to be properly mapped in the inheritance hierarchy. Alternatively you can make 'Concrete\Package\CommunityStore\Entity\Attribute\Key\StoreProductKey' an abstract class to avoid this exception from occurring. (0)
Related issues: #422 #439
Someone mentioned this to be the other day privately. It also resolved itself without any explanation.
You've tried clearing the cache, Refreshing Entities, etc?
Off course I did
It's a very strange one - every time it's happened to someone I've never had the opportunity to take a look at their site, it clears up before I get any further details.
Do you have any other add-ons installed at the moment?
- Community Store v.2.2.7
- Community Store Export Data v.0.2
- S3 Storage v.3.0.3
- C5j Stripe v.0.0.4 <- My private package
- C5J Usage Limit v.0.0.1 <- My private package
- Advanced HTML Block https://www.concrete5.org/marketplace/addons/advanced-html-block
Do any of those additional packages do things with attributes in their on_start controller functions?
We don't have any attribute stuff on the on_start
method. We just have the following on config.xml which runs on install/upgrade.
<attributes>
<attributekey handle="exclude_nav">
<value><![CDATA[1]]></value>
</attributekey>
</attributes>
Any updates?
It's not something I can replicate on my end, so there's not something I can investigate to fix. If you're able to package up your site and get it to me, I'm happy to take a look.
I just encountered this one again. Scenario is that it was chucking this error when navigating to the 2nd or more page of a CS product list block. I had had some memory issues creating thumbnails, so I'd been trying to up the memory limit through cPanel as root. For some reason that wasn't working, so I tried turning on php-fpm rather than fastcgi, but to no avail. I fiddled around a bit more, bodged it with ini_set in index.php and then the error started. I could not refresh entities or use page two of the product list.
I managed to fix it by clearing browser cookies for the site. Once I did that, I logged in again, refreshed entities and the product list now works as expected. Prior to clearing cookies, it did it all the time. Once cleared, it was all good again.
What's so strange about this is that cookies are involved... my guess is that it's some sort of corruption of cached doctrine files, maybe due to running out of memory, but how that relates to cookies I'm not sure about.
Yes I agree, it's bizarre. Just thought it was worth reporting in case it helps anyone else with the same problem.
I had this really wedge itself on a development site and the issue kept recurring, even with cache clears.
What I did in the end was add
'src/Concrete/Entity'
=> 'Concrete\Package\CommunityStore\Entity',
to this
protected $pkgAutoloaderRegistries = [
'src/CommunityStore' => '\Concrete\Package\CommunityStore\Src\CommunityStore',
'src/Concrete/Attribute' => 'Concrete\Package\CommunityStore\Attribute',
];
i.e.
protected $pkgAutoloaderRegistries = [
'src/CommunityStore' => '\Concrete\Package\CommunityStore\Src\CommunityStore',
'src/Concrete/Attribute' => 'Concrete\Package\CommunityStore\Attribute',
'src/Concrete/Entity'` => 'Concrete\Package\CommunityStore\Entity',
];
in the package controller and the problem seems to have gone away. From what I've read, the discriminator map is built up from the class hierarchy (instead of it having to be defined in the annotations on the base class as it once was - which was unwieldy for obvious reasons). I wondered whether this is some interaction with the opcache that might periodically break/interrupt the hierarchy, esp if the subclasses are loaded later, whereas telling C5 about them early might help the reflection class discover the subclasses at the right time (i.e. earlier?).
@gregheafield this sounds very useful.
Every time I've hit this problem myself, I've found it's something like:
- another add-on having been installed before Community Store
- and that add-in doing something in it's on_start (or some other early running function) calling a Doctrine related function
And what that seems to do is trigger all the discriminator map stuff to generate and complete, and then not get done for subsequent packages.
But likewise I've also see the problem sort of resolve on it's own, maybe from caching expiring, so it's a really tricky one.
So your solution here sounds promising. I have tried something like this in the past myself, but I reckon I may have just not gotten the mapping correct.
This just plain occurred out of nowhere in the days running up to a launch. There was no 'undo', or 'I just won't do that', so there was increased impetus to dive a little deeper as I didn't want it rearing up when it went live, even if I fluked it clearing the one time.
I've just realised, that I also took out the DiscriminatorMap annotation from the StoreOrderKey class. I don't think this was as important, but would potentially get in the way of the automatic discriminator mapping doing its job (we didn't have any orders in the system at that point, but should go back and retry the theory)
* @ORM\DiscriminatorMap({ "storeorderkey" = "StoreOrderKey"})
From the Doctrine docs (https://www.doctrine-project.org/projects/doctrine-orm/en/2.9/reference/inheritance-mapping.html#single-table-inheritance)
Things to note:
- The @InheritanceType and @DiscriminatorColumn must be specified on the topmost class that is part of the mapped entity hierarchy.
- The @DiscriminatorMap specifies which values of the discriminator column identify a row as being of a certain type. In the case above a value of "person" identifies a row as being of type Person and "employee" identifies a row as being of type Employee.
- All entity classes that is part of the mapped entity hierarchy (including the topmost class) should be specified in the @DiscriminatorMap. In the case above Person class included.
- The names of the classes in the discriminator map do not need to be fully qualified if the classes are contained in the same namespace as the entity class on which the discriminator map is applied.
- If no discriminator map is provided, then the map is generated automatically. The automatically generated discriminator map contains the lowercase short name of each class as key.
I've got multiple copies of the doctrine/proxies folder saved that it was generating, and could see it wasn't getting through generating them anymore. I need to do a proper diff on the tree to see if there is anything obvious that its leaving behind, but so far, its not had any recurrences.
We're also seeing this a lot on various sites - it seems to occur every time either the core or any package is upgraded. Usually resolved by clearing the Concrete CMS cache and then refreshing database entities.
I've just had another dose of this upgrading a site from 9.1.3 to 9.2.0. Started out on 8.5.7, went to 8.5.12, then 9.1.3 with no problem, but 9.2.0 was the final straw. I managed to get by, by clicking reload - I got an error about missing doctrine files so I ran:
concrete/bin/concrete5 c5:entities:refresh concrete/bin/concrete5 orm:generate-proxies
Then hit browser reload again. That seemed to fix it. I was able to rerun the upgrade without further error. I Tried upgrading to the latest CS too, but no joy.
I've got five packages installed. CS, DPS payment gateway, Custom shipping method, the theme package (built for 5.7) and cycle2 slider (built for 5.7)
Is this saying you're effectively stuck in this state, without being able to resolve the issue?
There's actually a 3.0 branch that @lvanstrijland has been working on, looking to refactor some items (one that hopefully can be merged in in the future).
In that branch there's some work there to solve the discriminator error side of things, it's beyond my abilities.
Specifically there is this function here: https://github.com/concretecms-community-store/community_store/commit/6a2872ecdfded82aedb525007933d9002054ce96#diff-345d0a8159751538dccfaacb0be1afb71ff33eb878dc77d88b802c348d83a947R569
Which appears to be called in the install function here: https://github.com/concretecms-community-store/community_store/commit/6a2872ecdfded82aedb525007933d9002054ce96#diff-345d0a8159751538dccfaacb0be1afb71ff33eb878dc77d88b802c348d83a947R112
I'm wondering if that's worth adding manually and trying in this scenerio.
No, not stuck. I got the exception, hit reload and got another error about a missing doctrine file. I rebuilt the proxies and database entities using the console commands, hit reload in the browser and I could then rerun the upgrade without further error. I took a backup before the 9.1.3->9.2.0 upgrade so I can always try that again to see what happens. You're not alone in feeling some of this is above your pay grade.