Manually inserting primary key with fluent mapping

esben · Post by **esben** » Mon 05 Sep 2011 12:36

Hi

I have created an entity model in Entity Developer and code is generated using the dbcontext template with "fluent" and "database independent" attributes set to true.

In that model I have an entity called "RetailerCategory" and the generated fluent mapping seems to be just fine.

Something along these lines (relevant parts only):

Code: Select all

            modelBuilder.Entity()
                .HasKey(p => new { p.RetailerCategory_Id })
                .ToTable("KAKATEGORIER", "dbschema");
            // Properties:
            modelBuilder.Entity()
                .Property(p => p.RetailerCategory_Id)
                    .IsRequired();

I have not configured any sequence, trigger use or anything else since i want to manually insert the primary key (Id).

However if I try to add a new instance of the "RetailerCategory" entity (with an Id set manually) to the context and save changes I get an Oracle error, saying the value cannot be null.

That is not so strange because the SQL (taken from DbMonitor) looks like this:

Code: Select all

DECLARE
  updatedRowid ROWID;
BEGIN
INSERT INTO dbschema.KAKATEGORIER(KAKODE, KATEXT, KAPROVKODE, KAPAKKAVGIFT, KAEDAT, KASIGN, KADGRFORFALL, KAFASTFORFALL, KAINSTITUSJON)
VALUES (:p0, :p1, NULL, :p2, NULL, NULL, :p3, NULL, NULL)
RETURNING ROWID INTO updatedRowid;
OPEN :outParameter FOR SELECT RetailerCategory_Id FROM infosoft.KAKATEGORIER WHERE ROWID = updatedRowid;
END;

The above code has no mention of the primary key (with columnname RetailerCategory_Id) in the insert part.

So how do I go about manually inserting the primary key when using database independent fluentmapping?

esben · Post by **esben** » Tue 06 Sep 2011 08:28

Just a bit of info on why I need this.

We have serveral import procedures, and deduplication procedures where we need to specifiy an ID (validated by something else to be valid) - in those cases we cannot rely on the triggers and we would rather not have to jump out into "ordinary" sql in order to get it right.

Shalex · Post by **Shalex** » Tue 06 Sep 2011 13:34

Please try to turn off IdKeyDiscoveryConvention:
http://msdn.microsoft.com/en-us/library ... 03%29.aspx.

esben · Post by **esben** » Wed 07 Sep 2011 06:59

Unfortunately that did not do a whole lot to the behavior, the generated SQL is still the same.

esben · Post by **esben** » Wed 07 Sep 2011 07:06

It did however lead me to a solution.

Disabling StoreGeneratedIdentityKeyConvention solves the problem.

I have yet to determine if has any other effect but so far the problem seems to be solved.

If you know of any "ill" side effects of disabling this convention I would be glad to hear it before I stumble upon them on my own.

Shalex · Post by **Shalex** » Thu 08 Sep 2011 10:23

You are right. Disabling StoreGeneratedIdentityKeyConvention is correct. There are no "ill" side effects.