I have implemented a pageable/virtual mode list class modeled from EditableRootListBase to support large database tables. Almost all the object saving code is copied directly verbatim from EditableRootListBase.
Basically, I would like to avoid calling SaveItem() when the object is not dirty. In my case, calling IndexOf() on an object not the cache is *very* expensive (at least on the first call) as it requires loading the entire set of primary keys determine which page the object would be on.
(Long story, but any change to the filter or sort on a paged list must clear the page cache, since the ordinal offset of any object in the cache is now wrong. Since the top row in the grid is the "current" item when this happens, the first thing that happens after the new sort/filter is applied is the current changes and a SaveItem() occurs on the the former top row, even if it wasn't changed. Oops, now that object isn't in the cache any more)
As I was looking at this it seem to me that the same issue exists (with less obvious impact) in ERLB. Even if an object isn't dirty, ERLB may clone the object and replace the original reference with the clone. So, one question is why ERLB itself doesn't treat SaveItem on a clean object as a NOP?
I could just change my class, but the the UI is agnostic as to the type of underlying list and just sees an IList of BusinessBase objects. Since a normal ERLB SaveItem can potentially return a new reference even if the object isn't dirty, I want to make sure my class works like ERLB to the extent necessary.
I'm currently working around this by pre-testing the object to see if is dirty and calling CancelEdit rather than ApplyEdit. Does this seem like a reasonable approach? Can you think of a better way to deal with this?
Copyright (c) Marimer LLC