User id - integer or UUID?
I have read previous discussion here about format of user_id
https://mail.python.org/pipermail/mailman-developers/2014-October/024024.htm...
That’s fine, I understand the issues.
The question is, I am storing user ids and it’s not clear to me if I should be storing them as INTs as returned by the REST API or converting back to UUID?
It’s important to get right now because Im going to use the same approach everywhere.
thanks
I’m going to store as string representation of the integer as I don’t want to be dealing with databases or anything else that makes a distinction between different types and lengths of integer. Ideally the identifier would match the core internal identifier which is UUID but since userid-as-UUID is not seen from the REST API side of things then I’ll act like that concept does not exist and hope I’m not making things more confused around user id.
On 1 Feb 2015, at 11:31 am, Andrew Stuart <andrew.stuart@supercoders.com.au> wrote:
I have read previous discussion here about format of user_id
https://mail.python.org/pipermail/mailman-developers/2014-October/024024.htm...
That’s fine, I understand the issues.
The question is, I am storing user ids and it’s not clear to me if I should be storing them as INTs as returned by the REST API or converting back to UUID?
It’s important to get right now because Im going to use the same approach everywhere.
thanks
Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/andrew.stuart%40s...
Security Policy: http://wiki.list.org/x/QIA9
On Feb 01, 2015, at 11:54 AM, Andrew Stuart wrote:
I’m going to store as string representation of the integer as I don’t want to be dealing with databases or anything else that makes a distinction between different types and lengths of integer.
That makes sense to me. Since Aurelien was okay with the status quo, I never did make the change described in that archive message.
Ideally the identifier would match the core internal identifier which is UUID but since userid-as-UUID is not seen from the REST API side of things then I’ll act like that concept does not exist and hope I’m not making things more confused around user id.
Yep, for now I think we'll keep the int-as-user-id concept, and it will be converted internally to a UUID. If/when we change that I'll have to keep backward compatibility with that API anyway.
Cheers, -Barry
That’s fine I’m good with that.
The other possibility, distasteful as it may be, is to make the changes to publish the UUID to the REST API and deprecate the use of the user_id as integer. I suggest this because others who come after me will have the same question and may run into the same issues as I have in trying to work out a “broadly compatible” way of handling/storing integers. They’ll probably come up with their own solution - perhaps to store user ID’s as a variety of integer types/lengths - perhaps to convert to UUID - perhaps to store integer-as-string, and the question might be raised again.
Short term pain now to move to UUID and deprecate user_id as integer, possibly longer term gain with clarity that a user_id is a UUID.
Anyway I don’t mind much anyway I’ll just do as Barry says…..
as
On 2 Feb 2015, at 9:33 am, Barry Warsaw <barry@list.org> wrote:
On Feb 01, 2015, at 11:54 AM, Andrew Stuart wrote:
I’m going to store as string representation of the integer as I don’t want to be dealing with databases or anything else that makes a distinction between different types and lengths of integer.
That makes sense to me. Since Aurelien was okay with the status quo, I never did make the change described in that archive message.
Ideally the identifier would match the core internal identifier which is UUID but since userid-as-UUID is not seen from the REST API side of things then I’ll act like that concept does not exist and hope I’m not making things more confused around user id.
Yep, for now I think we'll keep the int-as-user-id concept, and it will be converted internally to a UUID. If/when we change that I'll have to keep backward compatibility with that API anyway.
Cheers, -Barry
Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/andrew.stuart%40s...
Security Policy: http://wiki.list.org/x/QIA9
On Feb 02, 2015, at 10:04 AM, Andrew Stuart wrote:
The other possibility, distasteful as it may be, is to make the changes to publish the UUID to the REST API and deprecate the use of the user_id as integer. I suggest this because others who come after me will have the same question and may run into the same issues as I have in trying to work out a “broadly compatible” way of handling/storing integers. They’ll probably come up with their own solution - perhaps to store user ID’s as a variety of integer types/lengths - perhaps to convert to UUID - perhaps to store integer-as-string, and the question might be raised again.
Short term pain now to move to UUID and deprecate user_id as integer, possibly longer term gain with clarity that a user_id is a UUID.
I'm not sure we have a lot of options, given that JSON doesn't support UUIDs natively (IIUC) and Python's UUID objects have only these fields:
https://docs.python.org/3/library/uuid.html
Is a 32-character hex string better than a 128-bit integer? Does a urn string provide any benefit? 16-bytes doesn't seem helpful given that it would have to be encoded anyway.
Cheers, -Barry
participants (2)
-
Andrew Stuart -
Barry Warsaw