EntityRef Tracking

Jul 8, 2008 at 6:01 PM
This is a really great Job !

I just have One problem

All changes ton EntitySet is tracking perfectly, but how track Changes on EntityRef Property ?

I explain
My Class Contact has a Photo class.

I set Contact as ChangeTrackingRoot :




When i want Update my Database, my EntityRef is not tracked :


using (DBDataContext context = DBDataContext.GetContexteForWrite())



This a subset of my Class Contact


private EntityRef<LocalPhoto> _LocalPhoto;


Association(Name = "LocalPhoto_LocalContact", Storage = "_LocalPhoto", ThisKey = "PhotoId", IsForeignKey = true)]
DataMember(EmitDefaultValue = false)]
public LocalPhoto LocalPhoto{
get{ return this._LocalPhoto.Entity; }
    set { //  generated Code  "LocalPhoto previousValue = this._LocalPhoto.Entity; .... blablbal bla }


Jul 9, 2008 at 12:57 PM
Edited Jul 9, 2008 at 12:59 PM

Thanks for the compliment :)

In regards to your question, the reason why your LocalPhoto class is not tracked is because of the way you have your relationship - because its a foriegn key.

Tracking is done based on the one to one or one to many relationships, where one entity acts as the parent and another (or others) as child.  The foreign key represents a link back to a parent in the LINQ to SQL world.

In your case, the relationship says that a Photo has one (or more) Contacts, and the photo is the parent to the contact.  But the way you word your statement "My Class Contact has a Photo class", it sounds like each contact has a photo, making contact the parent, which is not what you have set you relationship in the DBML to be.

Let me put it another way, if you were going to convert it from a one to one into a one to many relationship, would it make sense to say that a Photo has zero or more Contacts? I'm not sure of what you business rules are, but in general world terms it may make more sense to say that a Contact has zero or more photos.

If I am right, your setting the contact as the root which is correct but you need to change the relationship direction so that it's Contact --> Photo instead of Photo --> Contact.  Also, check your database schema, from memory - by default if the Contact table has a PhotoId in it, the DBML diagram will assume that photo is the parent (i.e. a contact can't exist without a photo).  A better database design (from a maintenance point of view) maybe to put the ContactId in the Photo table instead - even though you may not support 1 to many now, you may want to in the future and it would be far easier to make this change in the future - you can control the one to one relationship through a database contstraint instead.

Hope this made sense.

BTW, if i've missed the point or my assumption is way off, please let me know ;)


Jul 9, 2008 at 7:25 PM
Edited Jul 10, 2008 at 8:35 AM
You are totaly right !

I will move my relationship in my database.
So, Contact will be the most top class, and Photo will be an EntitySet, even if there is only one photo per contact, for the moment !

  1. Remove key (PhotoId) in my Table Contact
  2. Add a key (ContactId) in my table Photo.
Now, no entityref to update, only entityrSet. I think this will be good.

Sorry for my poor english, I m from France ;)

Sébastien Pertus

And one more time, you have done a really great Job with this class !