-
-
Notifications
You must be signed in to change notification settings - Fork 618
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
GCM/FCM device uuid #386
base: master
Are you sure you want to change the base?
GCM/FCM device uuid #386
Conversation
@jleclanche I'm on the fence about making the GCM device_id a UUID. I think a CharField that can accommodate a UUID would be more appropriate for backwards compatibility. The guidelines indicate a UUID is appropriate but I don't have enough experience with the alternatives. For the device_id is to be useful when sending messages with a QuerySet then we shouldn't mess with the sent value too much or the developer will need to remember to translate the device_id to the appropriate format. Seems error prone. |
26aec34
to
637bb09
Compare
That page you linked talks about creating a random uuid. I think it's fine, tbh, but the main things that need to be tested are how the DRF API reacts to it, and how the migration holds up on an existing db. |
fd6093c
to
a07fd62
Compare
a07fd62
to
1e82f84
Compare
@jleclanche If we adopt UUIDs (and the provided UUIDField for storage and serialization) there is no way to support old data, even with a migration. Existing GCM apps would have to update their logic to send UUIDs because the UUIDFields expect full uuid values. To maintain backwards compatibility, and for the migrations data to work, we must provide a custom serialization uuid field that can accept the old values and left pad them before they are saved to the database. |
A data migration is all that's needed. Left-padding isn't necessary, UUIDs are just 128-bit ints. What's the issue exactly? |
Django's UUIDField doesn't accept some values we could expect from Android apps that aren't using UUIDs. Existing installations are likely to try values like
|
Are you talking about specifically DRF? If so, yes, I'm fine with us using a custom serializer wrapping UUIDField. |
Is this going to be ever merged? it's seems like a valid solution |
Bump! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this needs rebase
Is there any update on the same? We currently are not able to support iOS notifications via FCM. I can see that the fix is there but has been pending for a long time now? |
Replace HexIntegerField with UUIDField. Allows backwards compatibility through the REST API by left zero-padding values.
Resolves #358