Version 2.0

[ghost]

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.)

[ecbypi]

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.

[jim]

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?

[ghost]

User requests & issues that seem better to have here:

• Special Characters #143: Get countries without their special characters
• Add latitude & longitude for regions #142: Add Longitude & Latitude
• Subregions: undefined method 'named' for Array: [] #155: Return a RegionCollection instead of an empty array
• Country aliases/synonyms ("Vietnam" for "Viet Nam")? #54: Aliasing of countries, among other things.
• Different countries in different locales #93: Cleanup Jim said he wanted to reference later.
• Query for a region by name or code #156: Query in different ways

Can just use ticket number when referencing in discussion

[ghost]

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 👍

[michaelachrisco]

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.

[zarelit]

Any update on this? Also including continents would be cool (and there's a PR already!)
#176