Introducing parameters' DbType before passing on to the database - MsSql

[ayush3797]

Why make this change?

Fixes #475
Most column types will accept a string null and the db will automatically infer our intention, but for varbinary in MsSql the db complains that it cannot convert varchar to varbinary. For more details about the issue refer: https://stackoverflow.com/questions/29254690/why-does-dbnull-value-require-a-proper-sqldbtype

What is this change?

Changing how we form the parameters as we pass them to the database. Previously we used to only pass the parameter's value. Now, we would also pass the parameter's DbType along with the value as suggested in the stack overflow article.

Notes:

1. We would only be passing the DbType for MsSql.
2. Usually, we haven't seen any need to pass the DbType for Sql Server data types other than varbinary. However, we will still be supplying the DbType for all other parameter's for which we are confirmed about the 1:1 mapping from SystemType to DbType. Sql server datatypes like datetime, datetime2 are all treated as datetime by dotnet, so there is no 1:1 mapping for datetime datatypes. So we are skipping supplying the DbType for these.
3. As explained in this stack overflow article here, the GUID when converted to string, is output in lowercase. That's why when the query to verify the MsSql test InsertOneInSupportedTypes is written, we have explicitly cast guid_types to lower case.

Additional change

1. The real sql server datatype was incorrectly mapped to long dotnet type. It has been correctly mapped to decimal now.

Issue with DateTime/DateTimeOffset Sql Server data types

For a mutation request like this, we get a response:

and the parameters are generated as:

the parameter generated is of type DateTimeOffset (as evident from the value highlighted) but the underlying Sql Server datatype for the datetime_types field is datetime. Even though we supplied a value 1999-01-08 09:20:00 in the mutation, it became 08-01-1999 09:20:00 +05:30, because that's how graphql treats datetime/datetimoffset/date types. Then this implicit conversion from a value of type DateTimeOffset to DateTime cannot happen throwing an exception with message : Failed to convert parameter value from a DateTimeOffset to a DateTime. Hence we cannot add a mapping from typeof(DateTime) = DbType.DateTime.

Another option that came to my mind and would probably come to your mind as well would be to have a mapping fromtypeof(DateTime) = DbType.DateTimeOffset, since then there can be implicit conversion from value of DateTimeOffset type to DbType.DateTimeOffset. But that has its own flaws. Lets look at the below screenshots:

Consider this mutation:

and the parameters generated for the query (mutation ran successfully because the default value for the instant PK column was inserted into the table):

The parameter value is of sql server type datetime but the DbType is populated as `DbType.DateTimeOffset`. This upcasting cannot happen correctly and so we are returned with 0 records. So, this approach won't work as well.

Conclusion: We won't populate DbType for these sql server types as it is not required and would prevent data loss and any unforeseen exceptions.

How was this tested?

• Integration Tests
• Unit Tests - The unit tests that were skipped before saying that bytearray datatype is not supported are now running successfully for MsSql.

Sample Request(s)

Request method: POST
Request URL: https://localhost:5001/api/SupportedType/
Request:

{
    "bytearray_types": null
}

Response:

{
    "value": [
        {
            "typeid": 5001,
            "byte_types": null,
            "short_types": null,
            "int_types": null,
            "long_types": null,
            "string_types": null,
            "single_types": null,
            "float_types": null,
            "decimal_types": null,
            "boolean_types": null,
            "date_types": null,
            "datetime_types": null,
            "datetime2_types": null,
            "datetimeoffset_types": null,
            "smalldatetime_types": null,
            "bytearray_types": null,
            "guid_types": "27742da6-99f2-4e58-9fd8-4f143aea46b0"
        }
    ]
}

[Aniruddh25]

Thanks for this refactoring, discovering new issues and making sure the datatype is correct, no data loss for datetime/offset.
LGTM, after providing explanation in Code why DbType is nullable.