Let's look at an example of using ID's versus names for POSTS (creates)
Here is the region table. A region belongs to a division.
mysql> desc region;
+--------------+-------------+------+-----+-------------------+-----------------------------+
| Field | Type | Null | Key | Default | Extra
|
+--------------+-------------+------+-----+-------------------+-----------------------------+
| id | int(11) | NO | PRI | NULL |
auto_increment |
| name | varchar(45) | NO | UNI | NULL |
|
| division | int(11) | NO | MUL | NULL |
|
| last_updated | timestamp | YES | | CURRENT_TIMESTAMP | on update
CURRENT_TIMESTAMP |
+--------------+-------------+------+-----+-------------------+-----------------------------+
4 rows in set (0.01 sec)
Currently, if you want to create a region, you have to provide a division
"id" (as opposed to a division name)
POST /api/version/regions
{
name: "myregion",
division: 2
}
This allows the json to go directly into the table with one insert query.
if we use a division name instead, like this
{
name: "myregion",
division: "central"
}
then 2 queries have to happen on the server side. 1 query to fetch the
division id for "central" and then the insert query to create the region.
To do this right, imo, the ID for the central division WOULD be "central"
instead of the number 2 - and this is why natural keys make a lot of sense.
So rather than changing the api to accept cdn name, profile name, and type
name, continue to send thru the ids and we need to make the effort to get
to natural keys.
my 2 cents
On Wed, Nov 30, 2016 at 7:53 AM, Dave Neuman <[email protected]> wrote:
> Thanks Derek, it's actually already done, but then it dawned on me that it
> might break others, which is why I posted.
>
> On Wed, Nov 30, 2016 at 7:51 AM, Gelinas, Derek <[email protected]
> >
> wrote:
>
> > I've already got a bit of code you can use for just that if you like.
> > Doing the same for the config file lookups.
> >
> > > On Nov 30, 2016, at 9:50 AM, Dave Neuman <[email protected]> wrote:
> > >
> > > Hey all,
> > > I have been working on creating some integration tests for the Traffic
> > Ops
> > > client in the psql-rebase branch and fixing any bugs in Traffic Ops
> along
> > > the way.
> > > One thing I would like to change is to have the DeliveryService.create
> > and
> > > Deliveryservice.update in the Traffic Ops API accept cdn name, profile
> > > name, and type name instead of cdn ID, profile ID, and type ID. I
> > usually
> > > don't like to have clients worry about IDs, I think it should be
> handled
> > on
> > > the server side. I don't know who all is using the Deliveryservice
> > create
> > > and update APIs, if anyone, so I thought I would make the suggestion
> here
> > > and see if anyone is opposed?
> > > This change would be in a 2.x version of Traffic Ops.
> > >
> > > Thanks,
> > > Dave
> >
>
