TypeHandler is not called for parameterised constructor

[JoeStead]

We've had to create a TypeHandler to handle DateTimeOffset because SQLite has no concept of date/time, so it is saved as a string, which is fine. When querying the data back out, the Parse method is only called if it is being serialised to a type with a parameterless constructor. If a constructor exists which initialises all the properties the type handler is not called, which results in a "InvalidOperationException" with the following

A parameterless default constructor or one matching signature (System.String Id, System.String SomeValue, System.String SomeDateValue) is required for DapperTypeHandler.ParameterisedTypeConstructor materialization

Note how it is looking for SomeDateValue to be a string still.

I'm not sure if I'm explaining this the best way, I haven't been using Dapper for very long, so this may not be the best way of solving this problem. Below is a small, reproducible example using an in memory SQLite database.

using System;
using System.Data;
using System.Data.SQLite;
using Dapper;

namespace DapperTypeHandler
{
    class Program
    {
        static void Main(string[] args)
        {
            SqlMapper.AddTypeHandler(new DateTimeOffsetHandler());

            var dbConnection = new SQLiteConnection("Data Source=:memory:");
            dbConnection.Open();
            dbConnection.Execute(@"CREATE TABLE SomeTable (
                                      Id                VARCHAR,
                                      SomeValue         VARCHAR,
                                      SomeDateValue     DATETIMEOFFSET
                                    )");

            dbConnection.Execute(
                "INSERT INTO SomeTable (Id, SomeValue, SomeDateValue) VALUES (@Id, @SomeValue, @SomeDateValue)",
                new
                {
                    Id = "id",
                    SomeValue = "what up?",
                    SomeDateValue = new DateTimeOffset(2016, 02, 15, 16, 0, 0, TimeSpan.Zero)
                });

            var parameterlessWorks = dbConnection.Query<ParameterlessTypeConstructor>("SELECT * FROM SomeTable");

            //throws about not being able to find constructor (It expects the DateTime field to be a string still)
            var parameterDoesNot = dbConnection.Query<ParameterisedTypeConstructor>("SELECT * FROM SomeTable"); 

        }
    }

    class DateTimeOffsetHandler : SqlMapper.TypeHandler<DateTimeOffset>
    {
        public override void SetValue(IDbDataParameter parameter, DateTimeOffset value)
        {
            parameter.Value = value.ToString();
        }

        public override DateTimeOffset Parse(object value)
        {
            return DateTimeOffset.Parse(value.ToString());
        }
    }

    class ParameterlessTypeConstructor
    {
        public string Id { get; set; }

        public string SomeValue { get; set; }
        public DateTimeOffset SomeDateValue { get; set; }
    }

    class ParameterisedTypeConstructor
    {
        public ParameterisedTypeConstructor(string id, string someValue, DateTimeOffset someDateValue)
        {
            Id = id;
            SomeValue = someValue;
            SomeDateValue = someDateValue;
        }

        public string Id { get; set; }

        public string SomeValue { get; set; }
        public DateTimeOffset SomeDateValue { get; set; }
    }
}

[mgravell]

Thanks; I've pulled it in as an initial test, but haven't repro'd yet, due to SQL-Server talking natively in datetimeoffset, and SQLite not working properly on DNX451 (my test rig targets DNX451). Will evolve this (probably using a completely artificial test type) and see if we can get it working. The fun question will probably be around constructor resolution - i.e. how does that happen reliably (by name? by type?). Those are questions that can be deferred a bit when using properties / fields, but for a constructor, for example, there could be 3 constructors - choosing between them when none is an exact match and all 3 would require (say) 1 conversion... could be fun. Might need the caller to implement a custom ITypeMap to compensate.

[JoeStead]

I would have thought if there is an ambiguous constructor, it would just throw. Trying to infer the constructor precedence based on TypeHandlers/Maps/Whatever would easily lead to some very confusing scenarios, and given this issue seems to have gone undetected, it doesn't seem to be overly important?

[mgravell]

Indeed, I'm mostly aiming for "make it work". I have a spike on my local
clone with an artificial type ("struct Blarg", IIRC), so that I can make it
react in a provider-independent way - in progress.
On 16 Feb 2016 3:57 p.m., "Joe Stead" [email protected] wrote:

I would have thought if there is an ambiguous constructor, it would just
throw. Trying to infer the constructor precedence based on
TypeHandlers/Maps/Whatever would easily lead to some very confusing
scenarios, and given this issue seems to have gone undetected, it doesn't
seem to be overly important?

—
Reply to this email directly or view it on GitHub
#461 (comment)
.

[mgravell]

Should be fixed next build, but if you happen to be able to build locally and check it, I'd be eager to hear how it goes

[mgravell]

This is in 1.50.0-beta8 (the "beta" here is just because it includes the DNX targets, which is technically RC1). https://www.nuget.org/packages/Dapper/1.50.0-beta8

[JoeStead]

Awesome, haven't had chance to try it out yet, but will hopefully get round to it today. Thanks, really quick turnaround too 😄