Create the user_geos table for storing geo information derived from IP address.#9052
Conversation
4b9166c to
93e8d2b
Compare
| t.string :state | ||
| t.string :country | ||
| t.string :postal_code | ||
| t.string :latitude_longitude |
There was a problem hiding this comment.
Why not one each for lat and lng?
There was a problem hiding this comment.
For consistency with existing code?
E.g., https://github.com/code-dot-org/code-dot-org/blob/staging/bin/cron/process_forms#L93, https://github.com/code-dot-org/code-dot-org/blob/staging/bin/cron/index_users_in_solr#L63, etc.
That said, I'm very open to splitting them apart, I'm just following existing usage. In terms of DB usage, if they are ever going to be used, we would definitely want them stored as decimals for distance computations (which will already be slow enough already).
There was a problem hiding this comment.
Much as I like consistency, I can't see this not complicating future implementations
|
A couple tiny questions, but generally LGTM! |
| t.integer :user_id | ||
| t.timestamps null: false | ||
| t.datetime :indexed_at, null: false | ||
| t.string :ip_address |
There was a problem hiding this comment.
Do we want a ip_address_at timestamp, indicating the timestamp at which we obtained the ip_address from the user?
| t.string :country | ||
| t.string :postal_code | ||
| t.decimal :latitude, precision: 8, scale: 6 | ||
| t.decimal :longitude, precision: 9, scale: 6 |
There was a problem hiding this comment.
Note that we are running version 5.6.19 of MySQL, so are unable to take advantage of the Point object introduced in 5.7.
There was a problem hiding this comment.
Why are these not using the same precision?
There was a problem hiding this comment.
Both give six digits after the decimal point, since latitude is between -90 and 90 and longitude is between -180 and 180.
|
PTAL. |
|
Looks great! |
Design Doc: https://docs.google.com/document/d/1s5nYo8uSHWjCLWTtYCjLwTX5_E_ZwBVBRlOewN8tiw4.