Version 2.0
Opened this issue · 6 comments
Hey guys!
General discussion area for version 2.0. Any ideas? Drop 'em here and let's chat about it.
Jumping off points for discussion:
- Granular data sets
- Potentially moving to a database store & seed generator model for importing relevant geolocation data into rails apps (there would be a lot of caveats to this though if we did implement such a thing.)
Querying API
I was looking at #137 and thought it would impact addressing #43 where there may be other attributes we want to query by. This is mostly speculation that needs to be backed / vetted by looking through some of the data we'd be handling to address #43 to determine if we'd need to support querying by generic attributes.
If we do want to support querying by generic attributes (or want to avoid Country
being the special case), what are your thoughts on changing Querying#coded
to take a second attribute specifying the attribute to query by, defaulting it to :code
. This will keep Country
from being a special case.
def coded(code, attribute=:code)
unless query_collection.first.respond_to?(attribute)
fail "cannot search by '#{code}'"
end
# existing behavior
end
Supported Ruby Versions
Additionally, what versions of ruby do we want to continue to support in 2.0. 1.8.7 and 1.9.3 are EOL and unsupported.
Loading from a database
What are some of the caveats you were thinking of? I'm wondering what the motivation / use case for this would be. Not that I don't think there is one, but nothing comes to mind immediately.
Thanks for taking the lead on this @dainmiller and @ecbypi! The work you've been doing in this project is awesome.
Here are my thoughts on the points above:
Ruby Versions
We already only support Ruby 1.9, and I think it would be fine to only support 2.0+ in the next major version of Carmen. Or maybe 2.1+ since 2.2 is already out?
Querying interface
In terms of allowing arbitrary fields to be queried, there are four things that a user might need to be able to specify:
- What field to search in
- What value to look for in the field
- How to determine if there is a match (is it an exact or "fuzzy" match?)
- How many matches to return (all the matches or just one?)
So instead of adding more functionality to coded
, maybe a few new general methods can replace coded
and named
and provide a way for a user to specify all of the above:
illinois = us.subregions.first(alpha_2_code: "IL")
a_states = us.subregions.where(name: /^a/)
I'm thinking passing a Regex implies regex-based matching and a String implies exact matching (but should it still be case-insensitive?)
What do you folks think?
User requests & issues that seem better to have here:
- #143: Get countries without their special characters
- #142: Add Longitude & Latitude
- #155: Return a RegionCollection instead of an empty array
- #54: Aliasing of countries, among other things.
- #93: Cleanup Jim said he wanted to reference later.
- #156: Query in different ways
Can just use ticket number when referencing in discussion
Whoops, didn't mean to close and reopen. Was so stoked that we are down to 4 issues in total that I went crazy and started clicking stuff ... lol 👍
Although it might be out of Carmen's scope, a feature we have been trying to use is retrieving city/county data. I could see Regions containing Counties at the very least.