With duplicate fields in resultset, dapper doesn't throw an exception

[garethrepton]

If you have a query where two fields have the same name in a resultset, and in your dapper call you explicitly map to an object... something like:

Connection.Query<MyObjectWithIdField>("Select Id, 1 as Id from MyTable");

Dapper seems to be mapping the last instance of Id it finds in the row to the objects field. In this circumstance it seems like it should be throwing an exception as theres no way of knowing which of the Id fields are the intended result.

[mrgchr]

Hi,
I think that behavior is by design. Dapper does not throw when fields name is duplicated.
You can use splitOn parameter (like splitOn:"Id") in order to map more than 1 CLR objects in the query.

See following:
https://github.com/StackExchange/Dapper#multi-mapping

Following is a very simple one-one mapping example for you:

public class Person
{
  public int Id { get; set; }

  public string Name { get; set; }

  public Pet Pet { get; set; }
}

public class Pet
{
  public int Id { get; set; }

  public string Name { get; set; }
}

...
using (var conn = new SqlConnection(constr))
{
  string sql =
    @"SELECT 1 as Id, 'John' as [Name], 1000 as Id, 'Max' as [Name]
      UNION ALL
      SELECT 2 as Id, 'Bob' as [Name], 1001 as Id, 'Lucky' as [Name]";

  var personWPets = conn.Query<Person, Pet, Person>(sql, (person, pet) => { person.Pet = pet; return person; }, splitOn:"Id");

  foreach (var person in personWPets)
  {
    Console.WriteLine($"{person.Name}'s pet is {person.Pet.Name}");
  }
}

[garethrepton]

That makes sense for when SplitOn is specified, but without the SplitOn behaviour specified, I can't see a case where you'd want it to behave this way (i.e. SplitOn should change the behaviour to not throw if it is specified IMO).

Otherwise the fields are ambiguous, pretty much anything else that maps to that query would throw. If you created a temporary table with those columns specified, SQLServer would error.

[NickCraver]

This is indeed intended behavior - last one wins. If you want to avoid this, the suggestion is not to return those extra fields in the original query, since it's wasteful to do so anyway :)