DapperLib / DapperLib/Dapper

Using WHERE IN statement with custom type handlers results in "No mapping exists from object type ... to a known managed provider native type"

Open
#1,964 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C#
Stars
18.4k
Forks
3.7k
Avg merge
5h 8m
Merged PRs (30d)
1

Description

I'm not sure whether or not I'm doing something wrong with the library, however:

I have a custom type handler for one of my classess. When I use this type handler in general use with dapper, I have no issue with it being used properly when executing, say, inserts or querying for the data.

However, the moment I use, say, SELECT statements using WHERE IN, the query always fails with the error mentioned in the title, that is: "Using WHERE IN statement with custom type handlers results in "No mapping exists from object type ... to a known managed provider native type".

An example of such a query would be:
var readItem = await connection.QueryAsync<TestString>($"SELECT * FROM HelloWorld WHERE MyColumn IN @Vals", new { Vals = new List<TestString> { item1, item2 }.ToArray() });

Here, "TestString" is my custom type. it is for now simply a class with a single string property. I use a parameterized SQL statement with anonymous objects. I convert the list to an array because I've seen somewhere that it fixed the issue for others. However, it did not fix it for me.

Again, in all other use cases so far I've had no issues. It's the moment I introduce WHEREIN that things start to go haywire.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the reported QueryAsync call with a custom type handler and an array used in the WHERE IN parameter. Trace how the handler is applied for regular parameters versus values expanded for IN clauses. Done means the example executes successfully without the provider-native-type mapping error and existing parameter behavior remains intact.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp, sql
Domain
backend, databases
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.