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

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

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


   Maple/analytics is the quintessential use case for `It's not expected that ATC itself knows anything from their use, but rather external supplementary code around ATC that would.`  Delivery services currently need certain groupings for specific types of operational and analytics queries, and there's not an obvious system (like an asset management system) to keep that data.  Perhaps some of Rob's concerns could be alleviated by controlling the allowed tags for a particular TC installation?  At least in that case if there was semantic meaning it could be described in the enumerated tag list, and typos/etc would be somewhat mitigated.
   
   As for semantic meaning within TC, it basically becomes a rehash of continuing epic battle of dynamic versus static types.  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. 
   
   


-- 
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