Dlaczego dapper zwraca każdą kolumnę numeru jako Int64?

Question

Mam następujące zapytanie:

SELECT 
    [Person].[Id] AS [Person_Id], 
    [Person].[Name] AS [Person_Name], 
    [Address].[Id] AS [Address_Id], 
    [Address].[Number] AS [Address_Number], 
    [Address].[Street] AS [Address_Street],   
FROM [Person] 
LEFT JOIN [Address] ON [Person].[addressId] = [Address].[Id] 

który służy do kwerendy SQLite DB w pamięci jako:

var rows = _database.Query(query); 

Jednak gdy próbuję odczytać wartości jako Int32 mam InvalidCastException.

foreach (IDictionary<string, object> row in rows) 
{ 
    var someId = (int)row["Person_Id"]; 
    var someNumber = (int)row["Address_Number"]; 
} 

Powodem Używam dapper jak tak jest, że jako poboczny projekt buduję niektóre funkcje na górze dapper do mapowania wartości do POCO (Jestem świadomy podobnych projektów np rainbow, dapper.extensions itp).

Więc coś wzdłuż linii:

var rowVal = row[fieldName]; 
propInfo.SetValue(obj, rowVal, null);  

Znowu ignorować kosztów wydajności związanej z wezwaniem refleksji.

W powyższym przykładzie typ właściwości POCO to int32. Z tego powodu nie mogę przypisać tej wartości do obj.

Każda pomoc lub pomysły są bardzo doceniane.

Answer 1

To nie jest Dapper, to SQLite. Zobacz Datatypes In SQLite Version 3 (zakładając, że jesteś rzeczywiście przy v3):

Klasa przechowywania INTEGER, na przykład, zawiera 6 różnych typów danych całkowitych o różnych długościach. To robi różnicę na dysku. B ut tak szybko, jak wartości INTEGER są odczytywane z dysku i do pamięci w celu przetworzenia, są konwertowane na najbardziej ogólny typ danych (8-bajtową liczbę całkowitą ze znakiem). I tak w przeważającej części "klasa pamięci" jest nieodróżnialna od "typu danych", a te dwa pojęcia mogą być używane zamiennie.