Handling classes with Guid type properties and persisting them to a sqlite database. #1082
Conversation
…e issue: DapperLib#718). It implements the method suggested by numerous other users but leaves the byte order (endian) to the .net layer. It also fixes the guid equivalent issue raised in DapperLib#461.
|
Not to state the obvious but the error message "Sqlite is unavailable: Unable to load DLL 'sqlite3': The specified module could not be found." that you see in the CI tests (that target net252) can be fixed by copying the appropriate versions (x86 and x64) of the sqlite3.dll to Dapper.Tests\bin\Debug\net452\x86 (and x64) folders. |
|
First, thanks for the contribution! Unfortunately, there's a bit of history on why this functionality isn't in Dapper... We have decided not to support this scenario (and are encouraging the ADO.NET team to fix it at the shared layer). In short: Dapper is mostly provide agnostic, with very little special casing code. Due to bit order issues, what Dapper gets as a GUID vs. what anyone else gets as a GUID (e.g. Linq2Sql or EntityFramework or 20 others) depends on how you interpret the bits. Nothing is agreed upon here, it's per-provider. See #637 for context here...we'e been down this road before and regretted it. All that being said, let's see if we can possibly address this with type mapping in v2.0 where you can choose, rather than us choosing, how to store or query such a thing. That's really the only thing that's going to work for everyone depending on how they stored the data in the first place. |
This simple Guid handler should fix issue #447 (and duplicate issue: #718). It implements the method suggested by numerous other users but leaves the byte order (endian) to the .net layer.
It also fixes the guid equivalent issue raised in #461.
Note: this fix has only been tested against .net core 2.1.