I think once we get 2.0 in place we can start discussing the direction forward. I agree with the need for "natural keys" because I also was working on an integration test tool and found the need to "lookup" the "id" too cumbersome. Once 2.0 is in place, we should put these on the requirements on the list for 2.1.
On Wed, Nov 30, 2016 at 8:28 AM, David Neuman <[email protected]> wrote: > 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 > > >>> > > >> > > > > >
