Closed TroySchmidt closed 4 years ago
This issue is with making Dapper.FluentMap.Dommel compatible with Dommel v2. The new DatabaseGenerated option is set for the column property info. Updated the Fluent mapping project to make it initialize the properties correctly in the Dommel resolvers in the Fluent mapping project. FluentMap project
So this should work using Dapper.FluentMap.Dommel v2? Closing this for now.
So the bottom line issue is that the interface for ISqlBuilder allows you to write your own implementations for create statements, but not equal flexibility to write update and delete statements. Our use case is that all update interactions are ran via stored procedures so direct UPDATE
statements aren't allowed.
SqlBuilders are meant to handle database specific syntax, not to change the underlying query completely to a stored procedure. I don't really see why you would want to use Dommel if you're using stored procedures anyway.
Correct. So the SQL syntax for update could be something besides the default that just happens to be the same between the officially supported database backing. But allowing those methods does allow for other implementations that might require some more out of the box solution like if stored procedures were used to handle all DB mutations and not just dynamic SQL.
SQL is a standard language and basic queries are implemented the same across most relations databases. The select, insert, update, delete queries seem to work across most of them. The only exception is returning the ID generated by the database, that's the part which gets overridden in the current SQL builders.
Since Dommel is mostly about query generation, I don't the value of it when using stored procedures over using Dapper directly. To me this currently does not justifies expanding the ISqlBuilder
interface (and thus creating a breaking change) just for the sake of support stored procedures.
ISqlBuilder allows you to override the behavior for building the insert statement, but it is missing an equal method to update the update statement. The problem is the automatic update generation is trying to update the primary key field which it is using at the same time to find the record to update in the where clause. Our DBs (and probably most) don't allow the primary key to be updated directly.