views:

27

answers:

2

I have two tables in my application. The first one, Sections, stores content for a specific section of an online publication. This contains (among other things) the section title and a field CurrentRevisionId (FK).

A second table, Revisions, stores different revisions of that content. It has PK RevisionId field (the FK above, used to denote current revision), the HTML content itself, and SectionId (FK), specifying which Section the revision belongs to.

So basically I've got these two FKs pointing to each other. When I create a new Section, the child entity CurrentRevision is also populated with that content. But the InsertOnSubmit fails with this error:

The INSERT statement conflicted with the FOREIGN KEY constraint "FK_Sections_Revisions". The conflict occurred in database "xxxx", table "xxxx.Sections", column 'SectionID'. The statement has been terminated.

My guess is that it can't simultaneously create both rows and populate them with each other's PKs.

Should I insert the Section first, then the Revision (along with Section's PK), and then update the Section with the Revision PK? Or is there a better / more elegant solution to this?

EDIT: I've attached a screencap of the two tables with their relationships. Each Section has many Revisions (FK SectionID inside of Revisions table). Additionally, there is a one-to-one relationship where the CurrentRevisionId field in Section points to the revision which is "current". This "current" revision is where the application pulls the HTML from. Hope that clears things up a bit.

alt text

+2  A: 

You can't have FK's from 2 tables pointing at each other; it makes no sense.

If you are trying to model a many-to-many relationship, then you will need to create a mapping table inbetween the two tables. It will contain (at a minimum) two Foreign Keys, one to each of your 2 tables primary keys.

Mitch Wheat
Yep, that's the point i was getting at. A point on this, if you create the junction table with nothing but the FK's, EF will not even require to map this as an entity, it is smart enough to be 'aware' of the junction table without explicitly needing to map the entity in the model. Cool.
RPM1984
@RPM1984: HTH...
Mitch Wheat
After thinking about it, I agree that the two FKs doesn't make much sense. However, I don't think its a many-to-many relationship. Each Section has many Revisions, so I put the FK in Revisions. However, one of these needs to be "current".
Colin O'Dell
Perhaps I should place a bit field in Revision to identify the current one? That would allow me to remove the FK in Sections, and instead use a public method GetCurrentRevision which does `return Section.Revisions.First(r => r.IsCurrent)`? Would that be a better approach?
Colin O'Dell
@Colin O'Dell - your first step is to identify the multiplicity. If your saying "Each Section has many Revisions", then Revision should have a FK to Section. Section should not have any visibility of Revision. Yes - to get the "CurrentRevision", (if current is the 'latest' revision), it should be a MAX operation on the Revisions set of the Section.
RPM1984
Ah okay. Basically I had identified the multiplicity and added that FK correctly. However, I took the wrong approach in assigning/identifying the current revision. I think I'll need to use a bit field in Revisions though, since my application requires that users can submit new "potential" revisions for approval before going live (so MAX wouldn't work in this specific case, although I do understand your logic there.) Thanks to both of you for helping clear that up!
Colin O'Dell
+1  A: 
ShyamLovesToCode