AutoClone on update best practice

emathias posted on Friday, November 07, 2008

I ran headlong into the AutoCloneOnUpdate change for 3.5. I was assuming that I was working with the reference and kept getting errors that another user had updated the record timestamp.

This became an issue because I'm using the WPF CollectionViewSource with a list as the underlying data source. The object.save returns an updated object, but the underlying collection still reflects the previous state since the saved object is no longer a reference.

Does Rocky/anybody have a good recommendation for a best practice to assure that reference contains the same data returned by the save. I would prefer not to set the AutoCloneOnUpdate to not clone. It's certainly no problem to copy the data, I'm just thinking somebody has handled this a bit more elegantly.

RockfordLhotka replied on Friday, November 07, 2008

You need to rebind to the object that comes back from Save(). This may require creating a new CollectionViewSource if there's no way to tell it to start using a new object instance.

rsbaker0 replied on Saturday, November 08, 2008

I came up with a scheme where I've added a numeric "save generation" number to my BO's. When I save the object, I increment the generation number of the one that comes back (e.g. the one that you are supposed to keep), and then I negate the generation number of "stale" copy so that it is less than zero.

I've overridden AcceptChangesComplete() so it will raise a debug assertion if I ever call BeginEdit() on a "stale" object

I need to work on it some because it doesn't handle transaction rollbacks if the object is a child, but it seems to catch typical programming mistakes related to auto-cloning (e.g. reusing the old object instead of the one returned from Save()) pretty well.