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
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 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
wrote:
> sure but not exactly a small effort as you'd have to fix every part of TP
> that currently pass
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 Richards
+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 wrote:
> Hi all..we've discussed the possibility of moving t
+1
On Mon, Oct 8, 2018 at 3:51 PM Robert Butts wrote:
> +1. All the +1s.
>
> I do think there are some "real" IDs we might have to keep, where an ID is
> the real, only Candidate Key (maybe regex?), But for everything else, using
> the real Candidate Key will be _drastically_ easier to work with
+1. All the +1s.
I do think there are some "real" IDs we might have to keep, where an ID is
the real, only Candidate Key (maybe regex?), But for everything else, using
the real Candidate Key will be _drastically_ easier to work with. It'll
make posting a DS or Server without prior info 1 req inste
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
