Azure
[CLI]: Verb/Option for configuring "behavioral" feature flags (`--enable-feature-123`)
To track as a separate issue, I think we should add a different `dab` command that helps to enable or disable a feature, should not be only possible through the `init` command - which is the case today.
Originally posted by @Aniruddh25 in https://github.com/Azure/data-api-builder/pull/1983#discussion_r1468255119
Create a new command to create/update feature flags in the config file.
@severussundar can you elaborate on how this is different from feature introduced in #1983?
Let's keep in mind our discussion of feature flags: there will exist both:
- global feature flag section that holds true flags (
--enable-feature1)- This work-item applies to this bullet.
- a separate notion of new configuration properties exclusive to a feature (e.g.
cache,nested-mutations). - This workitem is unrelated to nestedmutations/inserts becuase #1983 implements nested mutations as an exclusive property within the global GraphQL config property ->--graphql.nested-create.enabled.
Let's keep in mind our discussion of feature flags: there will exist both:
global feature flag section that holds true flags (
--enable-feature1)
- This work-item applies to this bullet.
a separate notion of new configuration properties exclusive to a feature (e.g.
cache,nested-mutations). - This workitem is unrelated to nestedmutations/inserts becuase Feature Flag for Nested Mutations: CLI changes #1983 implements nested mutations as an exclusive property within the global GraphQL config property ->--graphql.nested-create.enabled.
Right now, the feature flag values (setting enabled:true/false, etc.) is possible only through init command. Also, this section of the config file cannot be updated using a CLI command as dab update is for updating fields under entities section only. This would mean that to update the feature flag values, users have to hand-edit the config file.
The goal is to come up with a new command that facilitates updating the feature flag related options. Having a global section in the config file will make it intuitive and also easy to implement.
Note: Although introducing a new Verb/Option will make the experience better, IMHO, shouldn't be a blocker for GA as users still have a way to enable/disable the feature (as well as configure feature specific properties).
Not nested mutation specific, but need to revisit in 1.1 to determine whether this is required immediately.
we need task to add new config field here for behavioral feature flags before this is implemented