Hey Traffic Controllers, Recently I added a Coordinate API to Traffic Ops [1]. With that, we now have a coordinate table in the database, so we have the ability to refactor some API backends that use lat/long pairs to use the coordinate table instead, such as the Cachegroups API.
My proposal is to keep the Cachgroup API as-is from the client perspective but update the DB schema by adding a Foreign Key (nullable because lat/long are optional) to the cachegroup table that references the coordinate table and removing the lat/long columns from the cachegroup table. For the API backend this means: POST: 1. create a row in the coordinate table from latitude/longitude in the request (skip this step if no lat/long in the request) 2. create a row in the cachegroup table with a FK to the coordinate row in step 1 PUT: 1. update columns in the cachegroup row 2. update lat/long in the coordinate row referenced by the cachegroup GET: 1. join the cachegroup and coordinate table on cachegroup.coordinate_id = coordinate.id to return coordinates in the response DELETE: 1. delete the coordinate row referenced by the cachegroup 2. delete the cachegroup row One hitch is that we need a unique name for the coordinate created from the cachegroup POST. This name doesn't have to be returned in the Cachegroup response, but I was thinking of just forming the name as cg_<cachegroupName>. Any objections, thoughts, or concerns? - Rawlin P.S. the Delivery Service API (missLat and missLong) could also go through this same pattern of refactoring too, but first I'll take care of Cachegroups. [1] http://traffic-control-cdn.readthedocs.io/en/latest/api/v13/coordinate.html
