Right sorry, 3.0 On Wed, Nov 30, 2016 at 8:40 AM, Jan van Doorn <[email protected]> wrote:
> > ... 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 > >>>>>> > >>>>> > >>> > >>> > >> > >
