Fix to ensure metadata returned follows JDBC data type specs

[barryw-mssql]

ResultSetMetadata of the ResultSet from DatabaseMetadata.getColumns() is Incorrect for Some Columns (1751)

Fix ensures the correct data types for each metadata column by mapping the data type from the SQL Server to the type specified in the JDBC spec

[lilgreenbird]

I think we just need to assertTrue or assertEqual that the expectedClass.getName().equals(columnClassName) as per repro in the issue

[barryw-mssql]

Changed the logic for checking the returned column data type matches the expected data type to simplify the logic. The new logic removes this Class Loader test. There is a new tests that actually compares the actual and expected class name for each column but does not use an assert. Instead a R_expectedClassDoesNotMatchActualClass message is used which includes the actual and expected data types as well as the column. This was done because if just an assert was used it would not show which column was generating the issue in the metadata result set.

[lilgreenbird]

pls run formatter on all files.

[lilgreenbird]

there should be a test case to cover the error msg R_colCountNotMatchColTypeCount path

[codecov]

Codecov Report

Attention: Patch coverage is 33.33333% with 70 lines in your changes are missing coverage. Please review.

❗ No coverage uploaded for pull request base (main@9b5036d). Click here to learn what that means.

❗ Current head 61ae9b6 differs from pull request most recent head 0ce310e. Consider uploading reports for the commit 0ce310e to get more accurate results

Files	Patch %	Lines
...soft/sqlserver/jdbc/SQLServerDatabaseMetaData.java	8.62%	53 Missing ⚠️
.../microsoft/sqlserver/jdbc/SQLServerConnection.java	59.37%	5 Missing and 8 partials ⚠️
...m/microsoft/sqlserver/jdbc/SQLServerException.java	50.00%	0 Missing and 3 partials ⚠️
...oft/sqlserver/jdbc/SQLServerPreparedStatement.java	87.50%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2326   +/-   ##
=======================================
  Coverage        ?   50.04%           
  Complexity      ?     3793           
=======================================
  Files           ?      143           
  Lines           ?    33179           
  Branches        ?     5631           
=======================================
  Hits            ?    16605           
  Misses          ?    14191           
  Partials        ?     2383           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Jeffery-Wasty]

This was mentioned in a previous comment above, but ensure that expectedClass is not null, don't assert.

[Jeffery-Wasty]

Suggested change

	assertNotNull(expectedClass);
	if (null != expectedClass) {

[lilgreenbird]

this really shouldn't even be necessary, we just defined this above, this would never be null

[lilgreenbird]

did we accidentally remove the check for isAssignableFrom that was in previous commit?

[barryw-mssql]

The expected class can be null if the the column label/name in the expected class lookup table does not match the actual column label from the result set (i.e. the lookup by column name will fail). This shouldn't happen but it is possible if there was a future code change or perhaps the returned metadata columns change.

Yes the IsAssignableFrom() is no longer used as I changed the BUFFER_LENGTH metadata class from Object to Integer. It was because of this generic Object class that we needed to use the IsAssignableFrom() check. Is The reason why it was originally specified as a generic Object was that the JDBC spec does not use the BUFFER_LENGTH column and so I reflected that as a generic Object being the expected data type. But in the code I have always ensured that BUFFER_LENGTH was an Integer. Therefore to simplify the logic and remove the IsAssignableFrom() check, I switched the expected class for the BUFFER_LENGTH column from Object to Integer.

[barryw-mssql]

I have kept the check but no longer use an assert to perform the check. I found that in the unlikely event there was an issue, a more detail error message was required that would include not just the actual and expected types but the column as well. Without the column name/label, it would initially be difficult t determine what the problem column was in the metadata

Changes are addressed