[GitHub] [trafficcontrol] rawlinp commented on pull request #4819: Tags blueprint

[GitBox <gi...@apache.org>]

rawlinp commented on pull request #4819:
URL: https://github.com/apache/trafficcontrol/pull/4819#issuecomment-852303923


   > I would actually come down on the side of allowing semantic meaning, mostly because first (as Jeremy pointed out) we already have a huge number of columns in the database, and second, actually getting new fields into production takes absolutely forever (serviceCategory -- didn't that take something like a year?). If we'd had tags we could have done that without a code change. While I appreciate the theoretical goal of have precise and fixed meaning for every TC related field, I think the cost in flexibility and "agility" is too high.
   
   I've been kicking around the idea in my head of just adding some kind of JSON `extensions` field to things like delivery services. Contrary to tags, these fields would actually have semantic meaning (with full API validation), but they'd exist within a `jsonb` column instead of a more static type. For example, when adding new fields to delivery services, if we chose to add them to the `extensions jsonb` column, we would **not** need to:
   - rev the API minor version
   - create/run a DB migration
   
   Clients would have to preserve all "unknown" fields within the `extensions` JSON, which would make the Go client experience a little tricky, but the Go client's existing behavior of basically dropping all unknown fields when it unmarshals JSON responses is one of the big reasons why we need to follow Semantic Versioning in the first place.
   
   This would definitely increase our agility in terms of adding new fields, but our _release agility_ is still a bit hampered by a number of other things, one of which being TO API major versions (which an `extensions jsonb` column wouldn't really fix).
   
   That said, there does seem to be a growing movement of "just add new DS fields as DS profile parameters, then make them real DB columns later" in order to get a more immediate deployment of features to things like `t3c`. Had we done that for Service Categories, it could've been deployed and used much sooner.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org