Closed DeagleGross closed 1 week ago
add Integration tests for dbstring (in a separate project Dapper.AOT.Test.Integration)
Hey @mgravell, I know you asked me to implement integration tests - I tried but I still dont have a solution yet. Filed an issue to do it in a separate PR: #122
regarding testing DbString
functionality: I packed Dapper.AOT, installed in local NuGet feed and used in a console app:
1) I can confirm that we emit a proposition to migrate from DbString
to [DbValue]
(only in Dapper.AOT mode)
[module: DapperAot]
2) confirmed that query against local database works and returns the model I have in database (note: we hit the breakpoint in the generated DbStringHelpers
- look at screenshot):
DbString
is a known type in Dapper and currently there is no dedicated support in DapperAOT for it.Current PR does 2 things regarding
DbString
: 1) in analyzer mode reports DAP48 and suggests to move from usage ofDbString
toDbValue
attribute. 2) properly configuresDbParameter
if one of parameter members isDbString
by setting.Value
,.Size
and.DbType
Implementation notes:
1) I have moved files in
Dapper.AOT.Analyzers
which are copied to the output in separate folderInGeneration
2) I have created a single code writer for such types (PreGeneratedCodeWriter
), and included the generation context options inGenerateState
to have a control over which pre-generated types to include in the output. I decided to do in order to avoid writingDbStringHelpers
in the output even in those cases, whereDbString
is not even used (basically to have more clear output)Questions:
1) I am pretty sure I messed up on how to get the size of DbString in ANSI encoding. How do we do it properly? 2) What exactly do we need to do with the
DbString
inUpdateParameters
? Do we need to call the same setup there, or just re-assigning value is fine?Closes #89