Open aaronburtle opened 6 months ago
"Book": {
"source": "dbo.books",
"relationships": {
"authors": {
"cardinality": "many",
"target.entity": "author",
"source.fields": [ "id" ],
"target.fields": [ "id" ],
"linking.object": "dbo.books_authors",
"linking.source.fields": [ "book_id" ],
"linking.target.fields": [ "author_id" ]
}
}
}
where validation for existence of these values in the database can't be done currently:
"linking.object": "dbo.books_authors",
"linking.source.fields": [ "book_id" ],
"linking.target.fields": [ "author_id" ]
needs discussion or additional details in this discussion thread to address:
This is an expensive call and outside the scope of the RuntimeConfigValidator class. Therefore, we should pre-load this information into our data model so that we can quickly retrieve it at time of validation.
Relates to https://github.com/Azure/data-api-builder/issues/1935
Validate that the fields listed in the below config properties are valid backing columns.
linking-source-fields
linking-target-fields
https://learn.microsoft.com/azure/data-api-builder/reference-configuration#many-to-many
When we do our validation of the config in the
RuntimeConfigValidator
one of the things that we would like to validate is that all of the source and target fields in an entity's relationships are valid backing columns in the backend database to which they ought to belong. This is easy enough for non-linking fields, as they exist in the source and target entities. Since source and target entities are defined in our config file, we have data structures which hold the relevant information for easy retrieval during validation.However, for linking objects this is not necessarily the case. Linking objects do not currently have to be defined as entities in our config, and therefore, to validate that the linking source and linking target fields that reference such a linking object are in fact valid columns within that linking object would require to go back to the backend and query the system tables. This is an expensive call and outside the scope of the
RuntimeConfigValidator
class. Therefore, we should pre-load this information into our data model so that we can quickly retrieve it at time of validation.Once that is possible we can add the validation step to the validator.