Rawlin, Anyway we could leverage the Physical Location table for this? Just a thought.
Steve On Thu, Jun 14, 2018 at 11:45 AM Rawlin Peters <[email protected]> wrote: > 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 >
