Currently, we are incorrectly handling the datetime datatypes. A snippet from BaseSqlQueryStructure class:
As evident from the highlighted portion, even for DateTime .NET type, we are parsing it with DateTimeOffset which is wrong. Just for an example, if you execute a GET request on the stocks_price table which has (categoryid,pieceid,instant) as PK, you would not get any result back even when the record exists for that PK in the table. Why? Because even though instant is a datetime column, it gets parsed as datetimeoffset column. This is shown in the next 2 images.
Also, in the current situation, even if you pass a datetime2/datetimeoffset value for a column which has date type, you would still go all the way to the database and get the exception. Ideally, in such a scenario, an exception should be thrown much earlier when DAB parses the value. This is again because we are parsing these values as DateTimeOffset as shown in the very first attachment.
Currently, we are incorrectly handling the datetime datatypes. A snippet from
BaseSqlQueryStructureclass:As evident from the highlighted portion, even for
DateTime.NET type, we are parsing it withDateTimeOffsetwhich is wrong. Just for an example, if you execute a GET request on thestocks_pricetable which has(categoryid,pieceid,instant)as PK, you would not get any result back even when the record exists for that PK in the table. Why? Because even though instant is adatetimecolumn, it gets parsed asdatetimeoffsetcolumn. This is shown in the next 2 images.Also, in the current situation, even if you pass a
datetime2/datetimeoffsetvalue for a column which has date type, you would still go all the way to the database and get the exception. Ideally, in such a scenario, an exception should be thrown much earlier when DAB parses the value. This is again because we are parsing these values as DateTimeOffset as shown in the very first attachment.