Add SQL file for SqlServer

[stefanedwards]

Pull request targets #157 .

Pull request also includes some features for unit testing (an EqualityComparer-class for IDataItem, and an extension for CollectionAssert that can use a custom IEqualityComparer to compare contents of list), moving the TestHelper-class from the Json extension, and finally a code coverage report to the github actions.

The commit from 3dfc61b contains the additional feature for supporting parameterized queries.

[markjbrown]

This feels like something that should get baked in at the core. I would think lots of source extensions would benefit from allowing users to store the query in a file versus putting inline.

@bowencode do you have thoughts on this?

[stefanedwards]

You're right. That would be better. Also considering that the CosmosSql extension uses the field "Query" vs. SqlServer's "QueryText". I can look into it. a) Do we want "QueryText" or "Query"? Regardless, there should be some backwards compatibility. b) Do we want a lax approach, and let the file be specified in QueryText, or a strict approach with explicit fields for either of them? Den 21. februar 2025 17.58.42 CET, Mark Brown ***@***.***> skrev:

…

markjbrown left a comment (AzureCosmosDB/data-migration-desktop-tool#165) This feels like something that should get baked in at the core. I would think lots of source extensions would benefit from allowing users to store the query in a file versus putting inline. @bowencode do you have thoughts on this? -- Reply to this email directly or view it on GitHub: #165 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[markjbrown]

I'm unsure which is the best way to do this, but I feel like the more common approach is to have properties that accept either inline text or a file versus explicit properties for each.

As far as the discrepancy between Cosmos and SQL source connectors I suppose I would add a Query property to SQL to unify the two interfaces. I don't know though, this is @bowencode's call.

[stefanedwards]

Alright. :)

I'll go for the Query option to cover both a literal statement and a reference to a file, but will await @bowencode's feedback.

[bowencode]

I don't think there's much difference either way. Neither is really confusing or a burden on the user. The single property adds a little extra logic to run every time but shouldn't be significant.

I don't see any advantage in shared code just to read a file to a string. These are just simple properties that are only superficially similar across different extensions with almost no additional code between reading the property and sending the result into the extension specific code.

[markjbrown]

Thanks @bowencode, makes sense.

@stefanedwards if you want to just add the property to the SQL extension go for it. Or if this is ready to go, let me know. This PR is out of date with the main branch. Just update. I'll rerun the checks and if good, we can merge.

Thanks.

[bowencode]

Code looks good and passed all my tests.