Hey, all.. we've discovered a discrepancy that was introduced recently in master in the new Traffic Ops Go api. I apologize for the length of this, but am leaving out some details to keep it a bit shorter...
Here's the problem: Many columns in the db that can be null are now represented as empty strings in the json output. In the Perl/Mojo version, they are represented in the json output as null, but in the Go version, they are empty strings. This can present problems with code that uses the json output if it distinguishes between null and "". We've seen this in testing when the Traffic Portal used the empty string value to update the ip6address column in the server table. I made an attempt to fix this problem with this PR: https://github.com/apache/incubator-trafficcontrol/pull/1549 -- it was merged accidentally, but then reverted with this PR: https://github.com/apache/incubator-trafficcontrol/pull/1557. I think my approach was ideal, but was a bit heavy-handed: any existing code (e.g. Traffic Monitor, Traffic Stats, or any external code using Traffic Ops Client) would potentially need to change to check for nil pointers where they would not have before. I see 4 approaches that could be taken: 1. Leave as-is. null db entries would be received in Go as empty strings and any client using them would have to be able to deal with them. New API endpoints in the Go code would (mostly) do the same. 2. Change to use pointers for these columns. Those pointers would be nil and any code (new and existing) would need to change to check for nil pointers in those cases. 3. Change so that those columns are omitted from the json data if empty. 4. Leave the existing structs in place for code that currently uses it and create new parallel structs with these columns represented as pointers. traffic_ops_golang and any new code should use these. That presents an additional support burden.. Personally, I think #2 is the best option long-term, but realize it does have drawbacks. Please let me know what you think.. Thanks.. Dan
