Closed ammmir closed 9 years ago
Well, there probably will never be "that one result struct", simply because the actual result completely depends on the database used. If you look at the official Python library there is some nice documentation about what database type can return what: https://github.com/maxmind/GeoIP2-python/blob/master/geoip2/records.py
That said I am not against a "per database type result struct" if I could put that together in a manageable fashion.
Otherwise there should always be the possibility to just force the Geolix result into the structure you need using Kernel.struct/2
and all default values you need. Or just pattern matching deep into the result and extracting the single values.
All responses are now structs matching the used database type, for example %Geolix.Result.Country{}
if you are using a country database. The individual result parts are also structs, for example %Geolix.Record.Location{}
for the location information (latitude, longitude, ...).
Please note that if some information are completely unavailable the result key will return nil
instead of an empty struct. These cases should be really rare as it mostly looks like a "country entry inside the city database", like "41.194.206.182". This behavior might change while adding support for the official web services.
Also have a look at the changed usage of Geolix.lookup/2
if you are querying a specific database instead of all available (and registered).
It would be better to define a struct, say %Geolix.Result{} where the map keys are always present, as opposed to building it up with Map.put, because right now, some keys, like subdivisions, are not added to the map for certain addresses, causing a crash.