You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by Rawlin Peters <ra...@gmail.com> on 2018/06/14 15:45:23 UTC
Refactoring Cachegroups for Coordinates
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
Re: Refactoring Cachegroups for Coordinates
Posted by Rawlin Peters <ra...@gmail.com>.
Yes, there are too many extra columns in the Physical Location table
to have it also contain the Coordinate and be referenced by other
tables that just need a Coordinate. Having Coordinates in their own
table keeps the DB more normalized.
- Rawlin
On Thu, Jun 14, 2018 at 11:37 AM, Steve Malenfant <sm...@gmail.com> wrote:
> Using Physical Location to hold the coordinate. Maybe there is just too
> much information in that table just to hold coordinate, but it seems sort
> of a duplicate.
>
> On Thu, Jun 14, 2018 at 1:35 PM Rawlin Peters <ra...@gmail.com>
> wrote:
>
>> Hey Steve,
>>
>> Do you mean adding a CoordinateID foreign key in the Physical Location
>> table? So that a Physical Location also has a Coordinate? Or tying
>> Physical Location to a Cachegroup?
>>
>> - Rawlin
>>
>> On Thu, Jun 14, 2018 at 10:41 AM, Steve Malenfant <sm...@gmail.com>
>> wrote:
>> > 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 <ra...@gmail.com>
>> > 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
>> >>
>>
Re: Refactoring Cachegroups for Coordinates
Posted by Steve Malenfant <sm...@gmail.com>.
Using Physical Location to hold the coordinate. Maybe there is just too
much information in that table just to hold coordinate, but it seems sort
of a duplicate.
On Thu, Jun 14, 2018 at 1:35 PM Rawlin Peters <ra...@gmail.com>
wrote:
> Hey Steve,
>
> Do you mean adding a CoordinateID foreign key in the Physical Location
> table? So that a Physical Location also has a Coordinate? Or tying
> Physical Location to a Cachegroup?
>
> - Rawlin
>
> On Thu, Jun 14, 2018 at 10:41 AM, Steve Malenfant <sm...@gmail.com>
> wrote:
> > 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 <ra...@gmail.com>
> > 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
> >>
>
Re: Refactoring Cachegroups for Coordinates
Posted by Rawlin Peters <ra...@gmail.com>.
Hey Steve,
Do you mean adding a CoordinateID foreign key in the Physical Location
table? So that a Physical Location also has a Coordinate? Or tying
Physical Location to a Cachegroup?
- Rawlin
On Thu, Jun 14, 2018 at 10:41 AM, Steve Malenfant <sm...@gmail.com> wrote:
> 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 <ra...@gmail.com>
> 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
>>
Re: Refactoring Cachegroups for Coordinates
Posted by Steve Malenfant <sm...@gmail.com>.
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 <ra...@gmail.com>
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
>