UID stored as integer instead of a string

[tomkersten]

I noticed the UID from OAuth requests are being stored as an Integer (cast via #to_i). I am not familiar enough with mongo to know whether there is significant performance gain by using an Integer over a string. However, this forces providers to use integer IDs for users, which is unfortunate (eg: UIDs are not an option).

1. Is there a reason this is stored as an Integer instead of a string (as the omniauth gem suggests)?
2. Is changing this an option/realistic?

[steveklabnik]

I don't remember why this decision was made.

Sure, it's realistic. It's a document store, there's no schema! Seems fine.

[wilkie]

Twitter uses integer uids, so it doesn't really matter. The reason why you are supposed to use strings is that you get the data in json, and ( tilts head ) javascript doesn't have a defined integer type. But, since the string can be converted to an integer reliably in ruby, it's not a problem.

There is theoretically no significant difference in storing the integer or the string version.

[tomkersten]

Right. I guess my question was brought up because I am interested in making it easy to integrate with other OAuth providers, and having this requirement requires all providers to use integers as their unique identifier for users. So, for example, a provider is not able to use UUIDs instead, because when it is cast via #to_i, it results in an ID of '0'...which is problematic.

[carols10cents]

I don't see why not.