utf8mb4_unicode_ci (mysql)

[jayesbe]

I am need of setting a length on the hash column in the Token entity.

In the Payum Core under Core/Bridge/Doctrine/Resources/mapping/Token.orm.xml

I need to add a length=191 on to the hash column. Whats the easiest way to override ?

I tried to extend the PayumBundle with MyOwnPayumBundle. I then tried to override the DI Extension class PayumExtension. Except that it wasn't finding the configuration tree. It seems I then need to override several other classes. Is there a better alternative ?

[makasim]

No need for the whole bundle. You have to add a listener and listen to load class metadata event.There you will be able to adjust the field parameters.

[jayesbe]

Actually I only had to use @attributeOverride :)

[The-Don-Himself]

@attributeOverride is definitely the way to go but it will affect Doctrine's generate entity command, I think this really should be handled in this bundle's model class and as such this issue should be re-opened for further discussion.

[makasim]

You can always create your own model that implements interface and define fields mapping as you'd like.

[jayesbe]

Wow old ticket, in any case.. @attributeOverride worked perfect.. I would expect doctrine's generate entity command to be affected. I've had to do this with other bundles as well and has worked without exception for the moment.

[The-Don-Himself]

@jayesbe Indeed @attributeOverride works, I have also encountered this issue in FOSOauthServerBundle as well and the override works there as well.

I think the issue is that these are only temporary solutions in my view and should be catered for in the bundle like FOSUserBundle did after many people ran into it.

https://github.com/FriendsOfSymfony/FOSUserBundle/issues/1919

Symfony docs have recommended utf8mb4 for about a year and a half now, this issue makes PayumBundle incompatible out of the box without @Override.

@makasim maybe if you don't want to change the length would you consider a mention in the docs? I can make a PR for either if you want.

[kirtixs]

We are facing the same Issue but somehow @AttributeOverride does not work, we tried it on two different systems where we first deleted the cache folder completely.

@The-Don-Himself are you still willing to submit a PR for this Issue?

[makasim]

You can always create your own model that implements the interface and define fields mapping as you'd like.

This is still the valid case. There is no need to use models from the bundle you can create your own with required doctrine settings.

[kirtixs]

Okay, we'll do that, but it's still weird that the default setup is broken.

[The-Don-Himself]

@redshark1802 I am willing to submit a PR for this because the changes required are really simple, maybe 15secs only but project owner @makasim has opted the community follow a different route which is his prerogative anyway and to be honest is equally simple with the bonus of learning a little bit more about Doctrine entities.

If your still having an issue, paste your entities and error and we'll help. For you're specific issue,my suspicion is that you have configured doctrine to cache metadata either in redis or apc hence deleting the cache folder wont help but either clearing redis from cli (nuclear option) of restarting apache (another nuclear option) but thae best is to run this command

php bin/console doctrine:cache:clear-metadata --env=prod

or

php bin/console doctrine:cache:clear-metadata --env=dev

[makasim]

@The-Don-Himself Don't get me wrong. I do not against the change and I see reasons behind it. The problem is such a change is a huge BC break and we simply cannot do it without bumping the major version.

We could think of other solutions, for example, we can add a new base model with a new metadata class for it.

[The-Don-Himself]

@makasim yes you're right, I keep forgetting that some changes, no matter how small will cause BC breaks. Perhaps just add it to the 3.x timeline and anyone who needs help can always follow this thread.