option to throw when result set has unmapped columns

[SurajGupta]

Here's a full description of the problem:
https://stackoverflow.com/questions/28678442/how-can-i-make-dapper-net-throw-when-result-set-has-unmapped-columns

The solution seems really hacky. This would be a great feature to have to proactively surface bugs in queries.

[JimPiquant]

This gets my upvote, even a debug only option would be helpful. With larger projects and teams this is a constant issue with Dapper.

[DarekDan]

Bad idea. Really bad idea. You want exception to be thrown? Use Automapper. Don't pollute decent micro-ORM due to someone's possible sloppiness.

[JimPiquant]

Pollute? That is a specious argument. Making software work by surfacing errors because of "sloppiness" isn't a bad idea, it helps make frameworks usable.

[DarekDan]

If you want full- or medium-ORM functionality, consider Entity Framework or linq2db.

[JimPiquant]

Using EF. Dapper is "a simple object mapper", not an ORM. It is the object mapping feature that would be easier to use and support if failures are not always silent.

[DarekDan]

Need I say more?

[BenJury]

If it were so important, wouldn't a better way be to write a wrapper to perform such a check and use it in your unit tests?

[JimPiquant]

Now your being just silly @DarekDan, keep it professional. An object mapper that fails to map throwing an exception doesn't come anywhere close to a SRP violation. Thanks for the suggestion @BenJury, but if the framework did this my unit tests would be far simpler and more likely to fail when someone gets "sloppy".

[SurajGupta]

@DarekDan - Yes, actually you do need to say more. What does Query<T> do? It maps objects AND executes a query. If you're an absolute purist about SRP then the fact that there's an AND in the prior statement means that Query<T> is a violation of SRP. But practically speaking, it's convenient to do those two things together. It's also convenient to provide some mechanism to inform the caller that there are unmapped columns. There is certainly a fine line; Query<T> and others shouldn't become a dumping ground for features. It is definitely in a spirit of Dapper to keep things simple. But in this particular case, I would argue that checking for unmapped columns actually furthers Dapper's goal of simplicity. Checking for unmapped columns is a key missing step in the existing workflow, and having to remember that that capability does not exist actually feels unnatural and introduces complexity into the consuming code. The workflow in my head, divorced from Dapper's specific implementation, is:

• map object to SQL statement
• validate that mapping isn't making a false assumption
• execute the query.

Also, and as a side note, I too would encourage you to keep it professional. Comments like "Bad idea, really bad idea" discredit you. I'm always suspicious when people talk in absolutes. Maybe you mean "in my experience, this kind of feature has in retrospect been a bad idea..." which would allow for others to chime-in with their experience and ideas.

[DarekDan]

It should not be responsibility of Dapper to make sure that all data points requested are mapped to properties of a POCO. That is silly and unprofessional, dear @JimPiquant and @SurajGupta. And Dapper is not an object mapper. Automapper is. Dapper only provides convenience extensions to map, but you could use it entirely with dynamic.

[JimPiquant]

Dapper is not an object mapper? Why is it then that the title in the Readme is "Dapper - a simple object mapper for .Net"?

[DarekDan]

I do recall many refer to it as micro-ORM. Object Relational Mapping. If you browse it on NuGet it reads:

A high performance Micro-ORM supporting Sql Server, MySQL, Sqlite, SqlCE, Firebird etc..

Can you use it to map ClassA to ClassB, I don't believe so. Can you use it to map relational data to a POC, yes, you can, hence a micro-ORM. We can split hairs here, deciding for StackExchange what it should be called. Bottom line, I will not support the idea of asking StackExchange to implement "properties mapping completeness".

Have you considered this approach instead? @SurajGupta
http://stackoverflow.com/questions/7778216/automapper-or-similar-allow-mapping-of-dynamic-types

[anton89]

Come on guys, pretty sure Dapper goal isn't simplicity rather it was performance so to implement this will introduce unnecessary overhead, which we all know happen in all full featured ORM

[DarekDan]

+1 @anton89

[SurajGupta]

@anton89 how so? If you add a bool parameter (i.e. throwIfUnmappedColumns) then you would only check for unmapped columns if throwIfUnmappedColumns=true You could set the default value to false for backward-compatibility. Performance would be equal to what it is right now. If you want to perform the check, then you take on the performance hit - which you should expect.