Dapper icon indicating copy to clipboard operation
Dapper copied to clipboard

Add ability to pass additional TypeHandlers to Query methods

Open goblinc opened this issue 5 years ago • 1 comments

We are currently refactoring a massive platform that we inherited from another company, and as part of that we are removing EF and updating it to use Dapper. Whilst doing so, we have found a major 'chicken & egg' problem caused by the fact that the TypeHandlers collection is a global static collection while trying to move some collections over to Dapper whilst maintaining compatibility with EF for other parts of the platform that we cannot yet fully refactor.

We have types that we would like to handle via a TypeHandler because there are occasions where the value is returned as a value that we then have to "decode" to get the entity, but when we register it, it causes problems elsewhere in the code that cannot use that TypeHandler because the entity is returned as a datatable.

We cannot remove the TypeHandler for just these calls because it's a static collection and breaks the calls to the methods that require them, and calls that could require the TypeHandler could be occurring in parallel on other threads (which is exactly what we are seeing).

It would seem a logical solution to allow the Query...Async<T> methods to pass in a list of additional TypeHandlers to allow on a per-query basis where registration of those TypeHandlers globally would cause issues.

Either that, or a mechanism to allow a TypeHandler to return something indicating that "I can't handle this" (or throw a custom Exception that can be caught by Dapper to signify the TypeHandler doesn't know how to handle what it's been given), and allow the default DataTable type handler to take over instead.

goblinc avatar Dec 01 '20 13:12 goblinc

I also stumbled upon this need; this functionality would also help me :)

doron050 avatar Oct 01 '25 21:10 doron050