+1 On Tue, Apr 30, 2019 at 1:00 PM Dave Neuman <[email protected]> wrote:
> +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 > > >
