You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is using Dapper 2.0.90 from Nuget and tested with both System.Data.SqlClient and Microsoft.Data.SqlClient.
Description:
When executing a MultiMapping query in the form of Query<T1, T2, TRes> and the splitOn column is NULL in the SQL result, Dapper behaves differently depending on whether the T2 type has a column with the name specified as splitOn parameter.
If T2 has a property with the name as specified in splitOn, the map-function receives null for the second parameter.
If T2 doesn't have a property with the name as specified in splitOn, the map-function receives an instantiated T2 object for the second parameter.
This is inconsistent behavior and breaks the usage of "surrogate splitters". Since this command is frequently used for left outer joins, it's no longer easily possible to check if the left outer join had matching row(s) or not - the second parameter passed to the mapper function is never null with surrogate splitters.
Example:
classT1{publicintId{get;set;}}classT2{publicstringName{get;set;}}conn.Query<T1,T2,bool>("SELECT 1 as Id, NULL as Name",(t1,t2)=>t2isnull,splitOn:"Name").First();//returns trueconn.Query<T1,T2,bool>("SELECT 1 as Id, NULL as Splitter, NULL As Name",(t1,t2)=>t2isnull,splitOn:"Splitter").First();//returns false
Expected result: both queries should return false.
Actual result: the first returns true, the second false.
The text was updated successfully, but these errors were encountered:
This is using Dapper 2.0.90 from Nuget and tested with both System.Data.SqlClient and Microsoft.Data.SqlClient.
Description:
When executing a MultiMapping query in the form of
Query<T1, T2, TRes>
and thesplitOn
column isNULL
in the SQL result, Dapper behaves differently depending on whether theT2
type has a column with the name specified assplitOn
parameter.If
T2
has a property with the name as specified insplitOn
, the map-function receivesnull
for the second parameter.If
T2
doesn't have a property with the name as specified insplitOn
, the map-function receives an instantiatedT2
object for the second parameter.This is inconsistent behavior and breaks the usage of "surrogate splitters". Since this command is frequently used for left outer joins, it's no longer easily possible to check if the left outer join had matching row(s) or not - the second parameter passed to the mapper function is never
null
with surrogate splitters.Example:
Expected result: both queries should return false.
Actual result: the first returns true, the second false.
The text was updated successfully, but these errors were encountered: