-
-
Notifications
You must be signed in to change notification settings - Fork 502
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Could not convert database value "11ead97b-ffa1-7458-a..." to Doctrine Type uuid_binary_ordered_time. Expected format: UuidV1 #329
Comments
Hi Luis, I may be able to help here as I'm getting this issue also with a new Symfony5 project. Except for me, the error would toggle. One request would work, refresh the page and then fail. Luckily I've used these ID's in past as a standalone package so I had an idea as to how to address. To be clear, I am no sure that this is the "correct" way, there could well be a bug here. The issue being that you may be dealing with string hex id values when you need to find using bytes. As part of the Symfony user auth mechanism the It's likely that you have a
A couple of points here - the Symfony SecurityUser calls the find with an array of values, eg $id == [$uuidInstance] so at this point I'm just checking on array and getting the instance. You must use a If you overwrite this find method, then it should work ok. Again, I think there is also an issue here but this is how I have dealt with it. As it's likely that I will have hex strings that I will need to convert to bytes, eg an api call with a user_id hex string, then I normally end up overwriting these methods to convert the string into a valid UUID instance to retrieve from the db. Or I make explicit repository calls. Then I know exactly what is going on and how to cast each $id value that is passed to the find. Note that I have never had an issue with So if this is a bug and it gets fixed, then great. Otherwise here is a workaround and a good tip for future to use the Criteria and getBytes() when needing to retrieve from the DB. |
Also to help with the bug report, the |
Hi @kylehqcom My case is slightly different than yours as I am implementing I'll try that workaround tomorrow - it's past 1am here now Also in my case I've seen Also it was working perfectly before my last update of ramsey/uuid so I think either a bug or a breaking change was introduced by accident somewhere and it doesn't play nice with ramsey/uuid-doctrine anymore |
Hopefully you won't need to "work around" as this seems related to here #327 Let me know if I can help out in any other way. Enjoy your sleep! Boa noite |
Just noted something: if you get the string representation of the UUID, the 13th character is the version indicator. However, the UUIDs being created have the 13th digit go off the range of valid versions. Here's some examples of generated UUIDs:
That's why
|
Hmmm, weird? Nice catch on your part however. That should help narrow down the issue 👍 |
weird indeed - so far havent spotted the culprit though |
So i found a possible fix Hopefully someone who know the code better than me can pitch in in file Lines 70 - 73
Lines 93 - 96
After this changes the error went away and so far it seems to work Could anyone tell me the purpose of that byte rearranging please? |
@537mfb I am getting the exact same issue. |
@Microtribute does commenting that byte rearrangement work for you as well? Do you know of any downsides/side effects to commenting them? |
@537mfb I don't know a possible fix. I used the |
@Microtribute Using uuid_binary instead looses what you gain with it beeing ordered in time - everytime you do an insert all indexes could need rearranged due to pagination. In a small/development database that's ok but in a large production database it could be a hit in performance |
I also encountered this problem after upgrading to The solution was to call However, something was broken also in my testsuite. So only the first data set from data provider in a test that accessed a reference to a fixture object (from Reference Repository) with I didn't have time to investigate it futher and downgraded to 4.0.1... |
@eXtreme can you tell me where to do |
@eXtreme thanks i will try this |
@eXtreme Thank you so much this worked for me |
ok - i may have an actual solution in
|
…"..." to Doctrine Type uuid_binary_ordered_time. Expected format: UuidV1'
Describe the bug
For the last couple of weeks I've noticed that in symfony UuidOrderedTimeGenerator is generating other than v1 Uuids intead of the expected v1, and that leads to throwing a converter error when validating the value
Exception message:
Could not convert database value "xxxxxxxx-xxxx-xxxx-x..." to Doctrine Type uuid_binary_ordered_time. Expected format: UuidV1
To Reproduce...
Setup a new symfony project with registration and authentication:
composer create-project symfony/website-skeleton symf
cd symf
composer require ramsey/uuid-doctrine
composer require symfonycasts/verify-email-bundle
bin/console make:user
bin/console make:registration-form
during this process choose to login automatically on registration success
bin/console make:auth
Basic project configuration:
Follow instructions given by make:auth to fix the return in onAuthenticationSuccess to a valid route (use bin/console make:controller DefaultController to create an empty controller to use here)
change config/packages/ramsey._uuid_doctrine.yaml to be:
Prepare your database:
bin/console doctrine:migrations:diff
bin/console doctrine:migrations:migrate
Run symfony's server or setup a vhost and go to the registration page http:///register in a browser. Fill out the form and click the register button
See output similar to the following:
on registration success a new entry is added to the user table in the database but during the login process the following exception is thrown and unhandled
Examining the value of the id it is not in fact validated as version 1
Expected behavior
A new entry is added to the user table in the database using the information typed in the form, login suing those credentials and redirect to the route setup in onAuthenticationSuccess .
Screenshots or output
Environment details
Additional context
This started happenning a couple of weeks back when i updated ramsey/uuid using composer update - can't remember what version i had before
The text was updated successfully, but these errors were encountered: