Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

UID stored as integer instead of a string #738

tomkersten opened this Issue Jan 18, 2013 · 4 comments


None yet
4 participants

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 commented Jan 19, 2013

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 commented Jan 21, 2013

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.

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 commented Jan 21, 2013

I don't see why not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment