Recommended persistence strategy / philosophy
leastbad opened this issue · comments
I am really excited to use GeoKit in my Rails app; I've already tested the functionality against the Google API and it works great for both specific and general addresses. Thanks so much for making this.
My goal is to make my User model acts_as_mappable so that I can display how far away other users are and show which users live in an area. Users are generally only going to set their location once, unless they move house.
Where I'm a bit stumped is how a GeoLoc should persist across sessions. In the unit test schema your example model has fields for street, city, state, postal_code, lat and lng. However, the Geoloc object is much richer than what you were saving, including suggested boundaries, country, and the full address. You don't even save the string used to generate the query.
Doing an API call every time I need to access their location seems wasteful because the result will be identical 99.9% of the time. On the other hand, I don't want to stash every attribute on my user model either.
What do developers usually do in this situation? I feel like it's supposed to be obvious but I haven't had the uh-huh moment yet. Is there a best practice for serialising a GeoLoc object so that it can be re-constituted later without having to call an API?
What is the role of the place_id?
Pete
Sorry @pjforde1978 - I'm more of a "passive maintainer" (I keep the project alive by accepting/rejecting pull requests from the gem users, but I'm not myself adding to the project at the moment, nor pushing a recommended "use".
Geokit/geokit-rails is really what you make of it. Some people will store a list of locations, and use geokit to give you the lat/lng so that when you next want to display it on a map, you have the lat/lng and don't need to query geokit.
I think generally once you've queried an address once, it's advisable to store it somewhere (stored cache, SQL database, etc), because like you said re-querying makes no sense for performance reasons.
Others might use this gem in all sorts of ways.
I didn't write the place_id things so I don't know. But I find when trying to understand why things exist, "git blame" (or good use of "gitk") helps explain the purpose/history of code.
I welcome any Pull Requests to improve the documentation of this project once you understand or form an opinion.