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 >
