yeah, what rob said. let's kill them but follow the correct api deprecation process to avoid any "surprises".
jeremy On Mon, Jun 28, 2021 at 10:02 PM Robert O Butts <r...@apache.org> wrote: > I'm +1 on getting rid of those fields, but unfortunately we need to support > them in older APIs. People have scripts that rely on them, and parse magic > data they've put in those fields. > > We can remove the field from the API in newer major versions. But we need > to somehow still serve it in the existing API versions (which will need > supported for at least 1 major ATC version after the deprecation is > announced). > > I agree, they're terrible and need removed. But I know for a fact there are > people putting arbitrary data in them in Production systems, which they > parse with custom scripts hitting the API. Even if we didn't know that for > sure, we still need to follow the Deprecation/removal process, to avoid > breaking users who don't necessarily follow the mailing lists closely. > > So, ATC 6.0 is about to be released, which introduces API 4.0. If we remove > `longDesc2` and `longDesc3` from API 4.0 and declare API 3.x deprecated in > ATC 6.0, we can remove API 3.x and older in ATC 7.0. Which will allow us to > delete the database fields in ATC 7.0. > > If we actually delete the database fields, we need to stop serving API 3.x > and older. We historically haven't removed API versions as often as we > could, mostly because it's painful to users. But serving a half-baked API > will cause all kinds of subtle bugs and data loss. If we delete the DB > field, we need to actually stop serving /api/3.x. > > > copy over all the data in the existing LD1 and LD2 fields, and append it > to the LD field, and drop the LD! And LD2 fields from the table. > > I'm not so sure about this, though. If someone has a specific format, > key-value, JSON, etc, just joining the fields is going to break their > scripts. It might be better to make the upgrade fail if the field isn't > empty, requiring users to handle and move or delete the data themselves > before upgrading. > > > On Mon, Jun 28, 2021 at 3:56 PM Chatterjee, Srijeet > <srijeet_chatter...@comcast.com.invalid> wrote: > > > Hi all, > > I’m proposing a change to the DeliveryService structure and database > > table, to remove the “Long Description 1” and “Long Description 2” > fields. > > These fields are seldom used, and can be replaced by the already existing > > “Long Description” field. In my migration, I’m planning to copy over all > > the data in the existing LD1 and LD2 fields, and append it to the LD > field, > > and drop the LD! And LD2 fields from the table. Pls let me know if you > have > > concerns with this change, or if you have a better way of doing this. > > > > Thanks, > > Srijeet > > >
