Why a hard reference to the column "id"
Opened this issue · 5 comments
Why a hard reference to the column "id" on line 112 in below code?:
Even when this column is NOT in an index.....
agreed, i've been bitten by this
Because that's how EntityFramework does it by default and drop-in replacement had to follow this convention, regardless of our personal opinions :)
We'd need something similar to EF ModelBuilder Custom Conventions to override default behavior.
However with Dapper.Contrib being just a bunch of extension methods to DbConnection
there is not much to attach configuration to. Distinguish by ConnectionString
won't work for multitenancy. Static won't work with multiple databases. And bunch of bool parameters with default values, or overloads, would be ugly, not convenient, and bug prone.
I agree that if you are not told a key and have an ID column, ID is a reasonable guess.
The main issue is ID persisting as a hard coded key if another key is declared on the table.
I agree that if you are not told a key and have an ID column, ID is a reasonable guess. The main issue is ID persisting as a hard coded key if another key is declared on the table.
That might trip over case where there is compound Key using that implicit Id column. If suddenly Id will stop being detected update might introduce breaking bug to existing projects.
Maybe [ExplicitKey(isKey: false)]
will be enough to fix it?
Having Id
column that's not a Key is an edge case, given how Dapper is used as upgrade/replacement to EF, so I'd go for option for disabling default behavior with full backward compatibility.
Having
Id
column that's not a Key is an edge case,
my use case is any integration with microsoft dynamics ; the primary key for entity X is always XId. it's a guid allocated by the system.
i wanted to call the column that was visible to the user "ID". i was using dapper. Hilarity ensued.
Perhaps a global dapper config "idIsImplicitKey" that defaults to True that can be turned off if needed.?