***** Update *****One thing I forgot to mention, is that I'm trying to save these as EntityCollections, not individually. I have an Entitycollection of MeetingEntities and MeetingPaperEntities. I was hoping that I could create all of these objects, save them in their respective collection, and then just call save on one of the collections. Sorry for the omission... *****End Update ***** Using the Adapter model.

I have 3 tables of concern: Meeting, Paper and MeetingPaper, where MeetingPaper is a M:N join table, with a few extra fields.

Both Meeting & Paper use Guids as the PK. I'm using Guid.NewGuid() in code, rather than SQL.

I'm trying to generate some sampledata for the application and run these two statements:

MeetingEntity mtg = new MeetingEntity(Guid.NewGuid());
MeetingPaperEntity mpe = new MeetingPaperEntity();
mpe.Meeting = mtg;

My expectation is that mpe.MeetingID will be automatically set to the Meeting's GUID. It isn't. So I'm getting the following:

mpe.MeetingID  // is an empty Guid.
mpe.Meeting.MeetingID  //is not an empty Guid.

However, if I save the Meeting first, and THEN set:

mpe.Meeting = mtg;

then I'm ok, and the MeetingID IS set. My question is why I should need to save the meeting before I reference it, since I'm generating the PK in code anyway. I was under the impression that if I saved things recursively, then all of this would be taken care of. Currently, I'm having to create and save my sample data objects in a precise order to avoid problems. I figure I could just manuall assign the MeetingID, but I like the convenience of not having to manually set both, so I'd like to understand what's going on and why if possible.

Thanks!

JeffD wrote:

***** Update *****One thing I forgot to mention, is that I'm trying to save these as EntityCollections, not individually. I have an Entitycollection of MeetingEntities and MeetingPaperEntities. I was hoping that I could create all of these objects, save them in their respective collection, and then just call save on one of the collections. Sorry for the omission... *****End Update ***** Using the Adapter model.

I have 3 tables of concern: Meeting, Paper and MeetingPaper, where MeetingPaper is a M:N join table, with a few extra fields.

Both Meeting & Paper use Guids as the PK. I'm using Guid.NewGuid() in code, rather than SQL.

I'm trying to generate some sampledata for the application and run these two statements:

MeetingEntity mtg = new MeetingEntity(Guid.NewGuid());
MeetingPaperEntity mpe = new MeetingPaperEntity();
mpe.Meeting = mtg;

My expectation is that mpe.MeetingID will be automatically set to the Meeting's GUID. It isn't.

PK Syncing is done after the PK side of the relation is saved IF the PK side is NEW. (Which is the case in this situation). If the PK side is not new, the FK in mpe is synchronized with mtg's PK when mtg is saved.

So I'm getting the following:

mpe.MeetingID  // is an empty Guid.
mpe.Meeting.MeetingID  //is not an empty Guid.

However, if I save the Meeting first, and THEN set:

mpe.Meeting = mtg;

then I'm ok, and the MeetingID IS set. My question is why I should need to save the meeting before I reference it, since I'm generating the PK in code anyway. I was under the impression that if I saved things recursively, then all of this would be taken care of.

That's correct, if you save mtg, mpe will be saved as well and mpe's FK will be synced with mtg's PK when mtg is saved, you don't have to worry about that.

The reason why the FK is synced when mtg is not new is explained above

Currently, I'm having to create and save my sample data objects in a precise order to avoid problems. I figure I could just manuall assign the MeetingID, but I like the convenience of not having to manually set both, so I'd like to understand what's going on and why if possible. Thanks!

No you don't have to do that. Just assign the objects to eachother and in the end save the graph in 1 go. You don't have to sync fk's and pk's yourself.

Thanks for the ridiculously fast reply Frans.

The PK syncing wasn't working when I tried it, but I just realized I was . Ok, time to start refactoring.

Thanks Frans.