One thing to be mindful of is that by just changing to natural keys, you're just gain is human clarity and reduction in unique constraints/fields. As an API user, you still have the N+1 problem because our REST API mirrors our db tables in most cases. It's still a great step forward, but there are still other concerns out there.
Jonathan G On 10/10/18, 3:57 PM, "[email protected] on behalf of Jan van Doorn" <[email protected] on behalf of [email protected]> wrote: So transition would be 1) add “natural keys” if not there 2) change foreign key references in schema 3) create new API version that use "natural keys” 4) deprecate old API that uses ID numbers 5) drop ID cols and sequences? ? Cheers, JvD > On Oct 10, 2018, at 15:35, Dan Kirkwood <[email protected]> wrote: > > the portal (and any other clients using API 1.x) would remain on 1.x using > ids until ready to take advantage of the cleaner 2.x with no ids... > > > On Wed, Oct 10, 2018 at 2:44 PM Jeremy Mitchell <[email protected]> > wrote: > >> sure but not exactly a small effort as you'd have to fix every part of TP >> that currently passes ID's to the 1.x api but i do think it would make a >> much better api. >> >> also, api 2.x should support patch imo. >> >> https://www.mnot.net/blog/2012/09/05/patch >> >> >> >> On Tue, Oct 9, 2018 at 8:22 AM Dewayne Richardson <[email protected]> >> wrote: >> >>> +1, but we need to consider it as an interim step, I think we need to >> also >>> start considering rethinking the API from the top-down (leaving the ID >>> based API's behind where possible). >>> >>> -Dew >>> >>> On Mon, Oct 8, 2018 at 3:44 PM Dan Kirkwood <[email protected]> wrote: >>> >>>> Hi all.. we've discussed the possibility of moving the major version >>> of >>>> the Traffic Ops API at some point in the (hopefully near) future. >> When >>>> that does happen, I'd like to propose that the change include >>> elimination >>>> of using foreign key ids (from the "id" field) and instead reference >>> using >>>> a different unique key. >>>> >>>> Most tables have such a unique key: name, username, hostname, etc, and >>> the >>>> API should be able to be upgraded to handle most cases fairly easily. >>>> >>>> Of course, more details would need to be worked out including >> maintaining >>>> an upgrade path and ensuring no functionality is lost, but wanted to >> get >>>> the idea out there for discussion. >>>> >>>> thanks.. Dan >>>> >>> >>
