If the field only applies to some DS types, it should be in its own table. Then it can be NOT NULL in that table, ideally with a constraint requiring the DS to be a type it applies to. You wanted to reduce the columns in the `deliveryservice` table, right? Here's your chance :)
On Wed, Nov 15, 2017 at 10:56 AM, Jeremy Mitchell <mitchell...@apache.org> wrote: > From what I can tell, there are 4 flavors of delivery services: > > 1. DNS* > 2. HTTP* > 3. STEERING* > 4. ANY_MAP > > And the properties associated with each flavor vary so I put together a > spreadsheet to show which properties pertain to each flavor: > > https://docs.google.com/spreadsheets/d/1rb4WzP1FicumyU1z6o_ > wasxD0ih1HoSH3bT-IA1GSlw/edit?usp=sharing > > First things first, anything look wrong there? Have I misrepresented / > misunderstood anything? > > Things that jump out at me: > > 1. dscp CANNOT be null yet it only applies to 2/4 of the delivery service > types (DNS* and HTTP*) > 2. regional_geo_blocking CANNOT be null yet it only applies to 2/4 of the > delivery service types (HTTP* and ANY_MAP) > 3. routing_name CANNOT be null yet it only applies to 3/4 of the delivery > service types (DNS*, HTTP* and STEERING*) > 4. What's up with ssl_key_version? Is this even used? I don't see it in the > TO UI or the TP UI. > > Suggestions: > > 1. we remove the NOT NULL constraint from dscp, regional_geo_blocking and > routing_name since they don't apply to ALL delivery services and rather we > enforce those fields in the API > 2. we get rid of the ssl_key_version column unless someone knows if it's > used and how > > Thoughts? Concerns? > > Jeremy >
