Consolidate data-source section

Summary

Consolidate custom database configuration options into the data-source object

Motivation

Group configuration options related to database connections into just one object to make it easier to identify and manage.

Functional Specifications

While not officially documented yet, the JSON schema provides support for a custom, database-specific section in the configuration file. For example, for Cosmos DB:

{
  "data-source": {
    "database-type": "cosmos",
    "connection-string": "AccountEndpoint=https://localhost:8081/;AccountKey=REPLACEME;"
  },
  "cosmos": {
    "database": "PlaygroundDB",
    "schema": "schema.gql"
  }
}

The proposal is to move everything inside data-source. I think there can be two options to do this

Option 1

The section is just moved into the data-source object, and renamed to a more friendly name, like "cosmos-options.

{
  "$schema": "dab.draft-01.schema.json",
  "data-source": {
    "database-type": "cosmos",
    "cosmos-options": {
      "database": "PlaygroundDB",
      "schema": "schema.gql"
    },
    "connection-string": "AccountEndpoint=https://localhost:8081/;AccountKey=REPLACEME;"
  }
}

Every database will be able to have their own options section, for example mssql-options or postgresql-options

Option 2

The database type value is turned into a full object:

{
  "$schema": "dab.draft-01.schema.json",
  "data-source": {    
    "cosmos": {
      "database": "PlaygroundDB",
      "schema": "schema.gql",
      "connection-string": "AccountEndpoint=https://localhost:8081/;AccountKey=REPLACEME;"
    }    
  }
}

Every database will be able to have their own section, for example mssql or postgresql

The second option seems better to me as more concise and with no data duplication and clearly defines the target database used along its options / configuration

[yorek]

Ok, let’s go with option 1, then (eg:

{
  "$schema": "dab.draft-01.schema.json",
  "data-source": {
    "database-type": "",
    "options": {
      "..."
    },
    "connection-string": "AccountEndpoint=https://localhost:8081/;AccountKey=REPLACEME;"
  }
}

[sajeetharan]

Hi @ayush3797 Since Cosmos DB has different underlying APIs hyphen is used to differentiate the underlying API. Yeah regarding having enums with C#, what if we change it to _

cosmosdb_apitype all in lowercase. - cosmosdb_nosql

Also regarding cosmosdb_postgresql yeah we can reuse the same implementation which we implemented for the native postgresql as @GaryHopeMS mentioned that existing implementation should work with the cosmosdb_postgresql connection string.

@mbhaskar kindly add your inputs as well