Iteration 2

[pwalsh]

Description

Next iteration on the API to expose more data, and refactor the model layer for adding additional data sources in near future.

Tasks

Model/Serialiser Refactor

• [x] Remove direct dependency on django-cities models
  • [x] Data migration writes from Django Cities to our own tables/models
  • [x] CosmopolitanContinent
  • [x] CosmopolitanCountry
  • [x] CosmopolitanCurrency
  • [x] CosmopolitanCity
  • [x] CosmopolitanRegion
  • [x] CosmopolitanPostCode
• [x] Serialisers use these new models
• [x] The primary key for each model should be a field explicitly called id, so we expose a standard interface even though the "primary key" has various different names like "code" or "name" in our data sources
• [x] Update test suite to test our own models/serialisers

  New endpoints

  Cities

• [x] City List /api/v1/countries/ (/api/v1/cities/?countries={id}, /api/v1/cities/?countries={id},{id},{id})
  • Can filter by country ids, or list of country ids
  • Fields per object:
  • id - should be the ascii name?
  • name
  • name_std
  • url
  • kind
  • country (an object of code and url)
  • region (an object of code and url)
• [x] City Detail /api/v1/cities/{id}
  • Fields:
  • ALL the fields directly declared on the City model
  • country, being an object with the same serialiser as the country list object
  • region, being an object with the same serialiser as the region list object

    Regions

• [x] Region List /api/v1/regions/ (/api/v1/regions/?countries={id}, /api/v1/regions/?countries={id},{id},{id})
  • Can filter by country ids, or list of country ids
  • Fields per object:
  • name
  • name_std
  • url
  • code
  • country (an object of code and url)
• [x] Region Detail /api/v1/regions/{id}
  • Fields:
  • ALL the fields directly declared on the City model
  • country, being an object with the same serialiser as the country list object
  • continent, being an object with the same serialiser as the region list object

    Postcodes

• [x] Postcode List /api/v1/postcodes/ (/api/v1/postcodes/?countries={id}, /api/v1/postcodes/?countries={id},{id},{id})
  • Can filter by country ids, or list of country ids
  • Fields per object:
  • id
  • name_std
  • url
  • kind
  • country (an object of code and url)
  • region (an object of code and url)
• [x] Postcode Detail /api/v1/postcodes/{id}
  • Fields:
  • ALL the fields directly declared on the PostalCode model
  • country, being an object with the same serialiser as the country list object
  • region, being an object with the same serialiser as the region list object

@kiote do cities have AlternativeName references? If yes, we'll need to provide lookups based on that data, and also include it in serialisers. Please advise.

[kiote]

also as mentioned in the slack discussion, we need to

• [x] change migrations to custom management commands

[pwalsh]

@kiote yes, just data migrations, not migrations for Models/Schemas

[kiote]

do cities have AlternativeName references? If yes, we'll need to provide lookups based on that data, and also include it in serialisers.

Every model: City, Country, etc have AlternativeName as ManyToMany connection, so we can use that as well (but AltNames are not imported yet).

So we possibly able to add to every detail endpoint this:

alt_names = ['name',...,'name']

[kiote]

For Postal Code model:

django-cities does not have a link to region there, just a string representation of region name and they could even not exist: https://github.com/coderholic/django-cities/blob/master/cities/models.py#L132

For now in our model I left it as it is, what would you suggest?

[pwalsh]

I'd suggest it be a foreign key to a region, which is part of our model.

[kiote]

okay, but what to do with non-existing and empty values? skip them?

[pwalsh]

sure, it means the field is nullable.

[kiote]

seems like this one is done?