Self-Tracking Entities: ApplyChanges and duplicate entities

re: Self-Tracking Entities: ApplyChanges and duplicate entities

Sean — Fri, 27 Apr 2012 00:37:39 GMT

Just an additional note on only using the foreign key ID: I needed to be able to attach the same Product to PurchaseDetailLines and was getting the error, but my grid view uses the Product.Name property. Since everthing related to products was read-only I was able to do a foreach loop through the detail lines and set the Product entity equal to null. The foreign key kept and I was still able to use the referenced objects before the save.

re: Self-Tracking Entities: ApplyChanges and duplicate entities

JA Reyes - MCPD — Wed, 22 Feb 2012 09:22:49 GMT

Hi @Martin,

Could you show how you override the Equals method?

Thank you.

re: Self-Tracking Entities: ApplyChanges and duplicate entities

Martin Robins — Sun, 22 Jan 2012 13:42:40 GMT

I ran into this problem a lot and found that it could also be resolved by overriding the Equals method of each entity class to compare the key values. Reading the above, are you saying that this should not have worked?

re: Self-Tracking Entities: ApplyChanges and duplicate entities

Koen — Thu, 03 Feb 2011 09:49:11 GMT

Thanks, this article provides some good insights.

We use kind of the same technique as in work-around 3.

Except we do it on the server-side, when a graph arrives at the server, right before calling, AcceptChanges. At this point, we search for duplicates and throw duplicates out.

This only works when the duplicates don't have changes them selves.

But this works out fine in our scenarios, where like in this example,

the duplicates usually come from a selection to link them to a Parent entity.

This took us quite some time to figure out though.

Some guidelines on what (and especially what not) is possibly with STE's would be nice.

Without such documentation, we keep running into "unexpected" issues like this, which take

a lot of time to figure out.

Still struggling with other issues, like re-linking detached entities.

(see social.msdn.microsoft.com/.../4fadd41f-3157-43cb-b5e1-7def59aacdb5)

We feel like STE's were/are not mature enough to go live with.

Thanks for your time,

Koen

re: Self-Tracking Entities: ApplyChanges and duplicate entities

mkamoski 1 — Wed, 22 Dec 2010 17:07:49 GMT

Diego --

This is a GREAT post and so very helpful.

I have a follow-up question.

Regarding this...

Only use Foreign Key values to manipulate associations:

Every time you would do something like this:

model.Make = make; //*1

…replace it with this:

model.MakeId = make.Id //*2

...am I correct in assuming that the default behaviour of STEs would be that if one sets the FK property (as noted in *2) then at that point the corresponding object property (which is model.Make in this case) would be invalid, etiher null or pointing to some object that is not necessarily correct AND, I further assume, that once that modified "model" entity does get back to the Context and ApplyChanges() is called and SaveChanges() is called then (and only then) will the object property (model.Make) be set properly and ready to consume and use?

What do you think?

Please advise.

Thank you.

-- Mark Kamoski