DBTrenches / SQLChecks

Helper functions and tests for SQL Server
MIT License
3 stars 2 forks source link

Can we keep the Azure/Non-Azure logic fairly contained? #8

Open taddison opened 4 years ago

taddison commented 4 years ago

To simplify the parameters this work would also move away from specifying any parameters that could be dervied from Config, including ServerInstance. The reasoning is that the function to execute queries will extract what it needs from the Config.

Assuming we have a configuration object that contains:

{
  "Connection": {
    "ServerInstance": "blabla.database.windows.net.",
    "ServerType": "Azure", // Blank is the same as OnPrem
    "Auth": {
      "Type": "Cert", // Could be Integrated/Blank/Credentials
      "CertPath": "Cert:\\blabla",
    }   
  },
  // rest
}

The only mandatory value is ServerInstance which then assumes auth is Integrated, and type is OnPrem.

Functions all pass $Config, and the SQL is actually executed by:

Invoke-SqlChecksCommand -Config $config -Query $query -Database $database

Under the hood this would leverage Invoke-SqlCmd or Invoke-SqlCmd2 and perform the necessary work to open the connection, if required.

This work would allow the Databases.tests.ps1 to be the consolidated source of database-level tests. This would require the Get-DatabasesToCheck function to be upgraded to support SQL Azure or OnPrem, with consideration given to caching.

In order to migrate without breaking existing functions we could use a check such as:

if($config.Connection) {
  # Use the new command (Invoke-SqlChecksCommand)
} else {
  # Use the legacy code as-is
}