Author: Greg Althaus
Level: Intermediate
Time: 5 minutes
From time to time, we get questions about why we chose to do something the way we did. Usually preceded by that looks really strange or a bizarre way to do that. Well, I won’t say we are always perfect, but we do think about how changes and new features can be rolled out without impacting the existing deployments. Double negatives are a way that we deploy features into the system without impacting current deployments.
Examples of double negatives
So… What’s up with all these double negative parameters and fields on objects? Here are a couple examples:
- Subnet Unmanaged field – why not Managed?
- Partial field on most objects – why not Full?
We often hide the choice in using a name that allows for the default to be the false value. Many years ago, we needed to add the Enabled field to the Subnet object. This turned out to be a big lesson point for us. We added it to the object. Users updated. All the subnets turned off.
Why have double negatives?
So, why? Since DRP is a golang binary that uses json object encoding, the fields are already present upon all the objects. Golang defines defaults for all object types. In the case of boolean fields, this is false. Our Enabled field when loaded from existing data objects got set to false. This turned off all subnets.
DRP’s data repository is often thought of as a database, but it is really a layered set of data objects from different sources (content packs, other servers in multi-site manager, and dynamic objects created by normal operation). There isn’t a direct concept of migration. This means that it can be a challenge to fix them up.
Hence, sometimes we name fields a little differently. Unmanaged on Subnet because it can default everywhere and upgrades can safely happen. Partial on objects that have parameters can default to false and only valid when returned true.
The follow-on concept is feature opt-in, but that is a topic for another day.
