Fair enough. I agree we should use natural keys. To me the ID thing is something internal to the DB that a client should not have to worry about. I can update the Traffic Ops client to support using IDs and keep the API as-is.
On Wed, Nov 30, 2016 at 8:26 AM, Jan van Doorn <[email protected]> wrote: > Agree with Jeremey. And we can't just slip in a change to 2.0 that does > part of this. > > I'm -1 on neuman's change, at least for 2.0. > > Cheers, > JvD > > > > > On Nov 30, 2016, at 08:23, Jeremy Mitchell <[email protected]> > wrote: > > > > 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 > >>> > >> > >
