-
Notifications
You must be signed in to change notification settings - Fork 178
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for enabling nested mutation from CLI #1950
Comments
Proposal: Property Name: Deafult behavior: Nested Inserts will be enabled be default. One more thing to note: When the property is updated to In the first iteration, hot reloading of this flag will not be supported. This can be added iteratively in the subsequent versions (if needed). @JerryNixon @Aniruddh25 @seantleonard @ayush3797 Please kindly share your thoughts. |
In future, we might also add support for nested updates. Having a stand-alone property directly in the config for nested inserts won't scale well. Instead, we should add an object (something like Also we should be creating objects for inserts/updates because we don't know what all inputs we might need from the user. In future, we might also allow them to specify the nesting limit (due to obvious payload size considerations). Then such a property can also go in the already existing json object. This is just one use case I can think of right now but more can come up as we move forward. "nested-mutations":{
"inserts":{
"enabled": true,
"nesting-limit": 10
},
"updates":{
"enabled": false,
"nesting-limit": 10
},
} Obviously, to start with, we would not add the section for |
Would this also be a possibility to reduce syntax? "nested-mutations":{
"*":{
"enabled": true,
"nesting-limit": 10
},
"inserts":{
"enabled": true,
"nesting-limit": 10
},
"updates":{
"enabled": false,
"nesting-limit": 10
},
} |
Yes, I am inclined to start off with just the Adding it now is pre-mature for the following reasons:
Also, I want to call out For the first version, the exact format of the feature flag would be "runtime":{
...
"graphql": {
...
"nested-mutations": {
"insert": {
"enabled": true/false
}
}
}
}
|
100% agree. |
CLI Option in the init command: Sample commands:
Right now, Nested Mutation operations are applicable only for MsSQL database type. So, when the option Warning message: |
Thanks for keeping the CLI in sync. Looks great. |
## Why make this change? - Closes #1950 - Introduces a feature flag in the config for nested mutation operations. - Feature Flag format: ```json "runtime":{ ... "graphql": { ... "nested-mutations": { "create": { "enabled": true/false } } } } ``` - CLI Option: `--graphql.nested-create.enabled`. This option can be used along with `init` command to enable/disable nested insert operation. - By default, the nested mutation operations will be **disabled**. - Nested Mutation operations are applicable only for MsSQL database type. So, when the option `--graphql.nested-create.enabled` is used along with other database types, it is not honored and nested mutation operations will be disabled. Nested Mutation section will not be written to the config file. In addition, a warning will be logged to let users know that the option is inapplicable. ## What is this change? - `dab.draft.schema.json` - The schema file is updated to contain details about the new fields - `InitOptions` - A new option `--graphql.nested-create.enabled` is introduced for the `init` command. - `NestedCreateOptionsConverter` - Custom converter to read & write the options for nested insert operation from/to the config file respectively. - `NestedMutationOptionsConverter` - Custom converter to read & write the options for nested mutation operations from/to the config file respectively. - `GraphQLRuntimeOptionsConverterFactory` - Updates the logic for reading and writing the graphQL runtime section of the config file. Incorporates logic for reading and writing the nested mutation operation options. - `dab-config.*.json`/`Multidab-config.*.json` - All the reference config files are updated to include the new Nested Mutation options ## How was this tested? - [x] Integration Tests - [x] Unit Tests - [x] Manual Tests ## Sample Commands - **Nested Create Operations are enabled**: `dab init --database-type mssql --connection-string connString --graphql.nested-create.enabled true` ![image](https://github.com/Azure/data-api-builder/assets/11196553/c1821897-1553-46d7-97d2-bf31b7f6178d) - **Nested Create Operations are disabled**: `dab init --database-type mssql --connection-string connString --graphql.nested-create.enabled false` ![image](https://github.com/Azure/data-api-builder/assets/11196553/ea421080-beb8-4f01-a2c9-99916b8b83cc) - **When --graphql.nested-create.graphql option is not used in the init command**: `dab init --database-type mssql --connection-string connString` ![image](https://github.com/Azure/data-api-builder/assets/11196553/d6f1d56c-a553-4dbf-8ad1-e813edc4274d) - **When --graphql.nested-create.graphql option is used with a database type other than MsSQL**: ![image](https://github.com/Azure/data-api-builder/assets/11196553/f9cdda69-f0bd-4e9d-8f65-dd1f0df48402)
Based on inputs, CLI Option: JSON property "runtime":{
...
"graphql": {
...
"multiple-mutations": {
"create": {
"enabled": true/false
}
}
}
} Further the feature (and consequentially, the CLI option name and JSON properties) is going to be renamed since The renaming of the feature, CLI option, fields in the config files are tracked under the issue: #2090 |
Closing this issue as PR #1983 is merged. |
This issue tracks the efforts needed for exposing the feature flag options through CLI commands and subsequently, serializing the same in the config file.
The text was updated successfully, but these errors were encountered: