Added multi-schema support for DTF Sql-Server

[AndreiRR24]

Added multi-schema support for DTF Sql-Server as requested in #105. Following the plan suggested by George, I've refactored the code to be able to use a custom schema name instead of the hardcoded "dt" as such:

• Added a new property in SqlOrchestrationServiceSettings called SchemaName, defaulting to "dt"
• Modified all the scripts under /Scripts by replacing "dt" with a placeholder called {{SchemaNamePlaceholder}} and also added explicit table accessing by specifying the schemaName for each access.
• Added a new parameter to all xxxParameter methods from the SqlTypes files under /SqlTypes and from SqlUtils, called schemaName to be able to remove the hardcoded "dt".
• Modified the SqlDbManager such that before executing the script commands, it will replace the schemaNamePlaceholder with the schema name from the settings. I found it to be the easiest way to replace the "dt" from the script files without rewriting the whole script. There is still room for improvement on this part and any suggestion is highly appreciated.
• Added a new test file to test if the program is able to create and delete a schema with a custom name.
• Modified the test files such that it will be able to test custom table names by adding a new parameter to the test method and replacing all the occurrences of "dt" with said parameter value.

As such, this version is backwards compatible as far as I know and is able to do all the operations with custom schema names.

Co-Authored-By: George Moldovan george.moldovan@uipath.com

[ghost]

All CLA requirements met.

[cgillum]

Awesome! Looking forward to going through this. I’m out of the country on vacation now but will do a full review when I get back in a few weeks.

[AndreiRR24]

While writing the test @cgillum suggested, I encountered a problem with the LogAssert: After creating the first schema and validating the following steps, the second schema validation fails with the following error even though after manual testing, the logic is right and the program is executing the flow correctly. This can be avoided by not running the second validation, but this doesn't sit quite right. Do you have any suggestions in solving this?

On another note, I do not know how to edit the documentation. I am guessing you mean this one and not the README.md file.

[cgillum]

On another note, I do not know how to edit the documentation. I am guessing you mean this one and not the README.md file.

Oh, sorry for not explaining this! Yes, I meant the published documentation. This documentation is authored via markdown files under the /docs directory. We're using GitHub Pages to have them published.

[cgillum]

I'm not sure about the validation error. The log validation framework was created by another contributor @wsugarman, so I don't have as much insight into how it works internally to know why you're seeing these unexpected failures.

[wsugarman]

While writing the test @cgillum Chris Gillum FTE suggested, I encountered a problem with the LogAssert: After creating the first schema and validating the following steps, the second schema validation fails with the following error even though after manual testing, the logic is right and the program is executing the flow correctly. This can be avoided by not running the second validation, but this doesn't sit quite right. Do you have any suggestions in solving this?

On another note, I do not know how to edit the documentation. I am guessing you mean this one and not the README.md file.

I haven't looked at this in awhile haha, but it seems that there is a missing log entry that was expected: "secondTestSchemaName._UpdateVersion". In short, the tests record the log entries in a list, and the extensions validate the contents of the log through the Expects methods: https://github.com/microsoft/durabletask-mssql/blob/main/test/DurableTask.SqlServer.Tests/Logging/LogAssertExtensions.cs

[AndreiRR24]

Updated the code with @cgillum's suggestions.