[Cache] Use non binary tag prefix #49713
Conversation
|
Thank you for your pull request! Can you please provide more details about the issue you encountered with PostgreSQL? Specifically, can you explain how the current implementation is causing the issue and how your proposed change addresses it and if it works with other DBMS? This information will help us better understand the problem and review your pull request more effectively. |
|
SQLite allows storing a binary string in the ID field. For PostgreSQL, it creates a |
|
I'd rather ensure we can store null chars in the column, those are allowed in keys. |
|
@nicolas-grekas, what about this solution #49741? |
|
The last idea :) @nicolas-grekas, will changing the ID column for PostgreSQL to |
|
We should instead change the type of the column. There is no other way. Keys can be binary, that's a fact. We could encode them indeed, but why, when we can just change the type of the column? |
yes indeed, out comments raced :) |
… in tags prefix (nicolas-grekas) This PR was merged into the 6.3 branch. Discussion ---------- [Cache] Fix DBAL deprecations and stop using NUL chars in tags prefix | Q | A | ------------- | --- | Branch? | 6.3 | Bug fix? | no | New feature? | no | Deprecations? | no | Tickets | - | License | MIT | Doc PR | - The change of the tag prefix is motivated by #49713. The other changes are to accommodate for deprecations in DBAL. Note that `DoctrineDbalAdapter::getServerVersion()` keep calling the deprecated `getWrappedConnection()` method because although the code says one should exist, there is no alternative way to access the server version. Drivers are all missing a `getServerVersion()` method (/cc `@derrabus` FYI) Commits ------- f4398a1 [Cache] Fix DBAL deprecations and stop using NUL chars in tags prefix
When using PostgreSQL binary part of the cache item ID loses.