I agree with you 100%, rob butts but i'd rather not tackle that big of a database refactor at the moment. :)
In the short term, I'd like to remove the NOT NULL database constraints from the columns that don't pertain to ALL delivery services. Sadly, overloading the ds table removed the ability to perform validation at the database level which I think is actually pretty important but I guess we can use the API/UI level validation for the time being. Jeremy On Wed, Nov 15, 2017 at 11:00 AM, Robert Butts <[email protected]> wrote: > 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 <[email protected]> > 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 > > >
