Dapper
Dapper copied to clipboard
DapperLib
CustomTypeHandler seems to doesn't work correctly
I have an entity like this:
[Table("Entity", Schema = "dbo")]
internal class Entity
{
[Key]
public virtual int Id { get; set; }
public virtual CustomType Filters { get; set; }
public virtual string Name { get; set; }
...
}
and custom type like this:
[JsonObject]
public class CustomType
{
[JsonProperty(PropertyName = "a")]public string a{ get; set; }
[JsonProperty(PropertyName = "b")]public string b { get; set; }
[JsonProperty(PropertyName = "d")]public IReadOnlyCollection<d> d{ get; set; }
}
custom handler like this:
public class JsonTypeHandler<CustomType> : SqlMapper.TypeHandler<CustomType>
{
public override void SetValue(IDbDataParameter parameter, CustomType value)
{
parameter.Value = value == null
? (object) DBNull.Value
: JsonConvert.SerializeObject(value);
parameter.DbType = DbType.String;
}
public override CustomType Parse(object value)
{
return JsonConvert.DeserializeObject<CustomType>(value.ToString());
}
}
and I register it in global.asax.cs like this:
SqlMapper.AddTypeHandler(new JsonTypeHandler<CustomType>());
The problem is that SetValue is not invoked when Execute is called. I'm using a Dapper.FastCrud, and my code to insert an entity to db looks like this:
var entity = new Entity
{
Filters = new CustomType{bla bla},
Name = "fafsd",
...
};
_dbConnection.Insert(dataExtractEntry, x => x.AttachToTransaction(tx));
Is there something more I have to do here?
I have this issue too, seems it was fixed here, Which was added to the 1.50.5 release so it seems. But I can confirm that using 1.50.5 does not solve the issue.
Can anyone advice how to check and debug for this error? Would like to know if something happen, how to debug and fix it. THanks.
How is this still an open bug after 4 years??? Is there any plan to fix this or is there at least a workaround?
This SO answer may be relevant: https://stackoverflow.com/a/56786941/986720
In version 2.1.24 this still happens. I have a custom TypeHandler for Ulid and SetValue doesn't get called, thus throwing the exception:
System.AggregateException : One or more errors occurred. (No mapping exists from object type System.Ulid to a known managed provider native type.) ---- System.InvalidOperationException : No mapping exists from object type System.Ulid to a known managed provider native type.
Are there any plans to fix this soon? Could I help in any way?
How is this still an open bug after 4 years??? Is there any plan to fix this or is there at least a workaround?
Don't be so rude and ask politely, after all this is an open-source free of charge library that Dapper devs do on their free time. If you want it fixed soon, the code is there to clone so go ahead and fix it yourself.
And yes, there are workarounds, I'm also affected by this issue and I've found a quite simple workaround to implement in my code.
How is this still an open bug after 4 years??? Is there any plan to fix this or is there at least a workaround?
Don't be so rude and ask politely, after all this is an open-source free of charge library that Dapper devs do on their free time. If you want it fixed soon, the code is there to clone so go ahead and fix it yourself.
And yes, there are workarounds, I'm also affected by this issue and I've found a quite simple workaround to implement in my code.
Careful there now, if you fall off that high horse of yours you're bound to get hurt.
A library doesn't do exactly what you want. That doesn't necessarily make it a bug; there are complex interactions that make this surprisingly subtle to implement without breaking other scenarios. Our highest priority is: not breaking existing usage. To quote from the license (apache):
Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
You are free to use it as-is, but the maintainers (mostly: me) do not owe you a fix, an apology, an explanation, or promises. That's not how this works. Anything - including this reply - is above and beyond any SLA that we have, because: we don't have an SLA with you.
Because of the complex interactions of this API and the lack of configurability (and the complexity of maintenance) in Dapper, a lot of active development is moving to Dapper.AOT - see https://github.com/DapperLib/Dapper/issues/1909 for more context/reasons. This is currently usable but incomplete. I can state that a revised and replacement API - with better design - in Dapper.AOT is more likely than a fix here.
You are also free to work on a fix that handles all scenarios, or fork and use a fix that handles just your scenarios.
