I looked into the history of this problematic code fragments, and I can see where in prior versions of my codebase (which were generated by pre June 1, 2011 nHydrate) the fields in question were marked System.ComponentModel.ReadOnly(true), but the set accessor
was public, not protected. Am I correct in concluding that the switch to protected was to fix a bug in how the schema got generated into code?
My problem is that I have several instances where I have master/child objects that I need to create. For example, consider Email and EmailRecipient:
id field is EmailID (database identity, int)
various other fields
associated with EmailRecipient via EmailID -> EmailID
id field is
EmailID (association to Email object)
Address (a string email address)
Previously what I would do is:
1) Create an instance of Email and add it to the object context via AddItem
2) Create an instance of EmailRecipient using the default/parameterless constructor
3) Assign a value to EmailRecipient.RecipientAddress
4) Assign the instance of Email to EmailRecipient.Email (which is the associated property of the relationship; sorry, that's the wrong terminology but I don't remember the right EF term offhand)
5) Add the EmailRecipient instance to the object context via AddItem.
6) Call Save() on the object context to save everything.
Since Address is no longer publicly accessible I'm going to have to add a step 1a - save instance of Email - and modify the creation of EmailRecipient to use the parametered constructor that takes an EmailID int value and a string email Address.
The additional Save (which is necessary to get an autogenerated value for Email.EmailID) will require another roundtrip to the server, which I'd prefer not to do.
So I'd really prefer the previous approach... :)