> ... requirements on the list for 2.1. For 3.0, you mean? No API breaking changes on a minor rev, I thought?
> On Nov 30, 2016, at 08:35, Dewayne Richardson <[email protected]> wrote: > > 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 >>>>>> >>>>> >>> >>> >>
