Hi, all.
In using denominator at netflix, I've noticed we can improve the way we represent "profiles" for reasons including compatibility with via json-pointer/patch. The change is to flatten "profiles" such as geo, as optional fields in the record set. I've reviewed this at length on IRC w/ jdamick and also with Allen here at netflix. I'd like to make this change soon as denominator 4 so that the model holds water longer thereafter.
Details:
Change:
from:
{
"type": "CNAME",
"qualifier": "US",
"ttl": 300,
"profiles": [ { "type": "geo", "regions": { "United States (US)": [ "Alabama"] } } ]
}
to:
{
"type": "CNAME",
"qualifier": "US",
"ttl": 300,
"geo": {"regions": { "United States (US)": [ "Alabama"] } }
}
There are 3 good reasons to do this:
1. data are now compatible with json pointer/patch specs. ex. geo/regions/United States. This makes ad-hoc client and PATCH operations straightforward.
2. weird relationships such as Alias + health check, are visible via optional fields as opposed to queries in a profile bucket. This makes that code simpler
3. mixed types in the same collection are not compatible with schemas like Thrift or Protobuf, so moving to extended fields allows us more flexibility
The original rationale for the profile collection is no longer necessary because:
1. the universe of potential extensions/profiles is much smaller than originally thought
2. vendors release extensions that would be modeled as profiles very slowly
3. the subset of extensions we support use in the next 6months - year is max 3-5 per record set, which is a reasonable amount of optional fields
4. we used to think no profiles = not special, but health checks can be placed on normal records.