Dapper.Contrib not passing key column with value

[erick2red]

Let me explain, because I could not find a proper title for this

I have this schema: ObjectX(ObjectXId(Guid), Name(Varchar)), and this POCO

public class ObjectX
{
  [Key]
  public Guid ObjectXId { get; set; }

  public string Name { get; set; }
}

Now, using Dapper.Contrib I write

var o = new ObjectX();
o.ObjectXId = mycustomGuid; // and this is unique
o.Name = "Foo";
sqlConnection.Insert(o);

And this code is failing with an exception inside Dapper, saying ObjectXId cannot be null. For some reason Dapper.Contrib is throwing away the value I passed as key.

Is it assuming the [Key] column will be autogenerated, or autoincremented?

[AndrewSmart]

I just ran into the same issue.

Is it assuming the [Key] column will be autogenerated, or autoincremented?

Yes.

Duplicate of #11. #11 was closed on June 7th with a claim that it works, but it would not then either.

I would say Dapper.Contrib does not currently support inserts for application supplied keys, conflicting with the Dapper.Contrib readme.md:

For these extensions to work, the entity in question MUST have a key-property, a property named "id" or decorated with a [Key] attribute.

My question is would the Dapper project welcome a patch to allow an application supplied key for inserts? I presume a new data annotation such as [NonAutoIncrementKey] or [ExplicitKey] would be an appropriate solution?

[johandanforth]

True, the Insert() requires the key property to be autoincremented/generated by the database. The readme.md could be more specific in that regard for sure. I have code running on my machine with added support for an [ExplicitKey] attribute for Insert, Update, Get and Delete which also supports non-integers (guids, strings etc) as (explicit) key. Seems to run well, and no breaking changes of the current interface. Note that the Insert() extension normally always returns an integer with the new id, but when explicitkey is used, 0 (zero) is always returned from Insert().

Comments or thoughts around this? Personally I think it's very useful to have application supplied keys and I have use for it right now actually :)

[AndrewSmart]

@johandanforth Sounds perfect! Thank you.

[erick2red]

@johandanforth While I think is another issue, SCOPE_IDENTITY doesn't work with MSSQL. I've have a tweaked version on my desktop using OUTPUT clause. I can send you a pull request if you like

[johandanforth]

@erick2red cheers for pointing at problem in contrib! If you think SCOPE_IDENTITY is an issue i MSSQL, could you please create a new issue for this? I think I know what you're thinking about :)

[johandanforth]

Sent in a PR for this now, for some reason I've lost my write access to the repo :) I've also added few more tests for SQLite and MsSql and etc... Perhaps you want to have a peek @AndrewSmart @erick2red

[NickCraver]

Fixes merged!

[bhx98]

I have same problem and finally found a solution:
[key] in dapper contrib define as "specify the property as a key that is automatically generated by the database" (in my case key was not auto_increment with default value and in mysql it creates error!)
[Explicti Key]: specify the property as a key explicity which is not automatically generated by the database)
=> _I found that for solving this problem we must to have auto id column without change any thing in databse_
with remove [key] from class and add [ExplicitKey] my problem solve completely
hope it helps you guys

[brendan87]

I'm still seeing this issue - I don't quite understand the comment from @bhx98. Was there a fix for explicitly stating the key?

[rajivverma]

There is still an issue apparently. Even with [ExplicitKey] attribute this error is thrown sometimes. I am unable to find any pattern, it is completely random.

See related stackoverflow post