Multiple-create: Schema generation

[ayush3797]

Why make this change?

Currently, for a create mutation (or any graphql mutation essentially), we can only do insertion/mutation in one table and not in another table which is related to this table via some relationship (either defined in config or in the database). This PR aims to:

1. Extend the functionality of the existing create mutations (which are basically point insertions) to allow insertions in related table.
2. To generate additional createMultiple mutations which will allow multiple nested insertions starting from the top-level entity.

Note: All changes made in this PR are specific to MsSql. Nothing changes for the other database flavors.

Quick glossary:

1. ObjectTypeDefinitionNode: Represents a table/view/stored-procedure. For a table, this contains all the column fields which belong to the table and the relationship fields which are defined in this table's entity configuration in the config file.
2. InputObjectTypeDefinitionNode: Represents an input object type we generate for mutations.

What is this change?

1. We no more ignore relationship fields while generating the input types for a create mutation: Till date, we were only considering the column fields in an object (of type ObjectTypeDefinitionNode) to generate the input type (of type InputObjectTypeDefinitionNode) for a table entity. But to support nested insertion, we would now also iterate over relationship fields to generate the input type for a create/createMultiple mutation.

2. Addition of linking entities at the backend: To support nested insertions in tables which have a relationship with cardinality N:N, the user can provide a linking table with the source defined in linking.object field which we need the user to provide. We need to generate an object type (of type ObjectTypeDefinitionNode) for this linking entity. This object type is later be used to generate the input object type for the linked tables.
   Additional details about linking entities:

   -> A boolean property IsLinkingEntity is added with a default value of false to the Entity record. This ensures that we are backwards compatible, and all the entities provided in the config are not considered as linking entities. For all the linking entities, this boolean property will be set to true.
   -> For a linking entity, the GraphQL and REST endpoints are disabled (set to false) by default. This ensures that we don't accidentally expose the linking entity to the user.
   -> MsSqlMetadataProvider.EntityToDatabaseObject contains database objects for Entities in config + Linking Entities. After we get all the deserialized entities, we will create entities to represent linking tables. The database objects for all the entities in config will be generated by a call to SqlMetadataProvider.GenerateDatabaseObjectForEntities() method which in turn sequentially goes over all the entities in the config and call the method SqlMetadataProvider.PopulateDatabaseObjectForEntity() which actually populates the database object for an entity.
   -> The method SqlMetadataProvider.AddForeignKeysForRelationships() is renamed to SqlMetadataProvider.ProcessRelationships(). The method now in addition to adding FKs to metadata, also creates linking entities for M:N relationships. This is done via a call to method SqlMetadataProvider.PopulateMetadataForLinkingObject().
   -> The method PopulateMetadataForLinkingObject() is a virtual method which has an overridden implementation only for MsSql. Thus, linking entities are generated only for MsSql.

3. ReferencingFieldDirectiveType: is a new directive type being added. The presence of this directive for a column field implies that the column is a referencing key to some column in another entity exposed in the config. With nested insertions support, the values for such fields can come via insertion in the referenced table. And hence while generating the input object for a create/createMultiple mutation, we mark such a field as not required.

4. Name of the create multiple mutation: is generated via a call to the newly added helper method CreateMutationBuilder.GetInsertMultipleMutationName(singularName, pluralName) which takes in the singular/plural names of the entity. If singularName == pluralName, the createMultiple mutation will be generated with the name: create{singularName}_Multiple else, it will be generated with the name create{pluralName}. The pluralName for an entity is fetched using another newly added helper method GraphQLNaming.GetDefinedPluralName(entityName, configEntity)

5. For create multiple mutations, the input argument name will be items which is stored in a constant string MutationBuilder.ARRAY_INPUT_ARGUMENT_NAME.

6. Object types (of type ObjectTypeDefinitionNode) for linking entities will be generated using a method GraphQLSchemaCreator.GenerateObjectDefinitionsForLinkingEntities(linkingEntityNames, entities).

7. sourceTargetLinkingNode: The object type for linking entity is later used to generate object type for a sourceTargetLinkingNode which will contain:
   -> Fields present in the linking table (but not used to relate source/target)
   -> All the fields from the target entity.
   This is done using a call to the newly added method GraphQLSchemaCreator.GenerateSourceTargetLinkingObjectDefinitions().

8. Renamed method GraphQLSchemaCreator.FromDatabaseObject() to GraphQLSchemaCreator.GenerateObjectTypeDefinitionForDatabaseObject() to better convey what the method is doing.

9. To make code more streamlined and bug-free the method SchemaConverter.FromDatabaseObject() is broken down into smaller chunks which handle smaller and easy to read/comprehend responsibilities. Passing of existing test cases confirm the refactor.

10. Added a method GraphQLUtils.GenerateLinkingEntityName(sourceEntityName, targetEntityName) which concatenates the names of the source and target entities with a delimiter (ENTITY_NAME_DELIMITER = "$") between the names and prefixes the concatenated string with: LINKING_ENTITY_PREFIX = "LinkingEntity" string.

11. Added a method GraphQLUtils.GetSourceAndTargetEntityNameFromLinkingEntityName(string linkingEntityName) which returns the the names of the source and target entities from the linking entity name.

12. Split the CreateMutationBuilder.GenerateCreateInputType() method which was used to create input types for Relational (Pg/My/Ms/Dw Sql) and non-relational dbs (Cosmos_NoSql) into two new methods: CreateMutationBuilder.GenerateCreateInputTypeForRelationalDb() and CreateMutationBuilder.GenerateCreateInputTypeForNonRelationalDb().

13. Split the CreateMutationBuilder.GetComplexInputType() method which was used to build input types for Relational (Pg/My/Ms/Dw Sql) and non-relational dbs (Cosmos_NoSql) into two new methods: CreateMutationBuilder.GenerateComplexInputTypeForRelationalDb() and CreateMutationBuilder.GenerateComplexInputTypeForNonRelationalDb().

Validations Required:

1. Ensure non-conflicting names of fields in sourceTargetLinkingNode for N:N relationships: Object types are generated for sourceTargetLinkingNode for a source, target pair of tables (refer above for what all fields would be present in this object type). The name of the field (either a relationship field or a column field) in the target entity might conflict with the name of the column field in the linking table. Hence, we need a validation in place to ensure that if there is a conflict, we catch it during startup (currently this check is done during schema generation) and throw an appropriate exception with an actionable message.
2. Ensure non-conflicting names of relationship fields in column fields in one entity: This is a validation which is required in the current architecture as well and is a bug (see here: [Known Issue] Relationship name and exposed field name of an entity must not overlap #1937). This is required to ensure that relationship field names don't conflict with the exposed names of column fields in a table.
3. Ensure we have values for FK referencing fields to perform insertions: All the fields in a table which hold a foreign key reference to some other column in another entity are now nullable in the generate input objects for create mutation. This is because we assume that the value for such a field might come via insertion in the related entity/table. However, if the create mutation does not include a nested insert, the value of such a field still has to be specified by the user (unless the field is nullable/has default at the database level as well in which case we can give a null value/default value for the field- although this is highly unlikely since the field is a foreign key). If we don't get a value for such a FK referencing field:
   -> Either via nested insertion , or
   -> By the user
   we should throw an exception accordingly. This will maintain backwards compatibility. UNLESS THIS VALIDATION IS IN, WE ARE NOT BACKWARDS COMPATIBLE.
4. Ensure there is only one source of value for FK referencing fields: If the user is providing a value for an FK referencing field, and there is a nested insertion involved which also returns a value for the same field, we should throw an exception as there are two conflicting sources of truth. In short, exactly one of the sources should provide a value.

How was this tested?

• Unit Tests - Added to NestedMutationBuilderTests.cs class.

Sample Request(s)

[Aniruddh25]

Looks good! Please get this in. No more changes other than any simple stylistic or obviously wrong assumptions.

[ayush3797]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[ayush3797]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).