Calling Developers!
We are reenergizing our code contribution process! Learn More

What are the Slack Archives?

It’s a history of our time together in the Slack Community! There’s a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.

Because this space is not active, you won’t be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..

Hello guys. I've discovered an issue of case-insensitive storage keys by getting duplicate key value

UKHUU3NE9 Posts: 17 🧑🏻‍🚀 - Cadet

Hello guys. I've discovered an issue of case-insensitive storage keys by getting duplicate key value violates unique constraint error messages in the propel.log for instance for "spy_glossary_storage-unique-key".

The storage sync process converts the source of the key to lower-case in the corresponding *_storage database table and, for instance the translation, frontend process converts the requested key also to lower-case to get the data from the storage, e.g. Redis.

Currently I can create in ZED two cms blocks with the names "cms BLOCK" and "CMS block" successfully, but for which I can not get the data for both from Redis in YVES.

Is there a way to fix this (or a reason why this is implemented like this)?


  • Afaik this is also DB specific.
    Mysql is usually by default case insensitive, whereas Postgres is case sensitive.
    So depending on the type of DB one would need additional validation in the forms to ensure input matches the expected results in other parts of the system (and e.g. Redis).

    UKHUU3NE9 Posts: 17 🧑🏻‍🚀 - Cadet

    I am not sure if this is an issue here, maybe querying would be, should be checked/tested than.

    I tested locally on Postres with an extension of \Spryker\Service\Synchronization\Model\KeyFilter and removing the mb_strtolower() function. The keys and the general process are looking good so far.

    The other way round would be the more challenging approach. How to keep the source of the storage key unique while not allowing only lower-case letters (unique column, sql trigger, custom propel behavior) ?

    Btw: the hole topic is only relevant for storage keys based on a string column. For eaxmple Products, etc. use the id in the storage key.