+1 to Rawlin's latest proposal. If we can get consensus then let's close the PRs for previous solutions and move forward with this one.
Thanks, Dave On Fri, Apr 26, 2019 at 3:58 PM Rawlin Peters <[email protected]> wrote: > On Wed, Apr 24, 2019 at 10:53 AM Robert Butts <[email protected]> wrote: > > We might even be able to do a little better than that, and only have one > > handler, no separate versions in the routes/handlers. So, the route would > > look something like: > > > > func Update(w http.ResponseWriter, r *http.Request) { > > inf, userErr, sysErr, errCode := api.NewInfo(r, nil, nil) > > dsVer := tc.NewDeliveryService(inf.Version) > > api.Parse(r.Body, inf.Tx.Tx, &ds) > > ds := dsVer.Upgrade(inf.Tx.Tx) > > I think that could be doable, but I think that would imply having to > go update every minor-versioned-struct's `Upgrade` method whenever a > new minor version is added. That is, each minor-versioned-struct would > need to maintain instructions on how to upgrade to the latest version > of the struct. That maintenance cost would increase with every added > minor version, which is why I was thinking it should really just chain > together, upgrading/downgrading the request. That way when adding a > new minor version, you'd only be on the hook for writing instructions > to upgrade from the previous minor version to the latest minor > version, without having to touch any of the other minor versions. The > less we have to touch the previous minor versions, the easier it would > be for us to support _all_ minor versions, which means TO clients > would last longer without needing to upgrade (as opposed to just > supporting the "latest" minor version of the API and dropping all > other minor versions from one major TC release to the next, like > Jonathan has described). > > A downside to chaining would be that each minor version upgrade you > have to do is an extra DB query, so if a client is on the oldest > possible minor version, they could be taking a decent hit on added > latency. But, if it becomes a problem for the client, they would have > added incentive to upgrade to the latest minor version. If we drop > support for all but the latest minor version of the API when we > upgrade to the next major TC version, I think that would mean we'd > really only be supporting two minor versions at any point in time, so > maybe doing it the way you've proposed in the code snippet above would > be the same amount of work at that point anyways. > > - Rawlin >
