ObservableHashSet collection changed notifications

[sjb-sjb]

I am using change notifying entities. Entity Framework Core uses ObservableHashSet for the collections as described in https://blog.oneunicorn.com/2016/11/16/notification-entities-in-ef-core-1-1.

The problem I have encountered is that when I call ObservableHashSet.Clear, the collection change notification that it generates is a Replace change with OldItems = the current items and NewItems = an empty list. Semantically this would appear to be fine, however it doesn't play well with .NET and UWP classes.

Specifically, the UWP ListView class expects that Replace only occurs with an equal number of new and old items -- in other words, a 1 to 1 replacement. To delete items in a ListView one must use a Remove notification instead of a Replace. Consequently, one cannot bind a ListView to the collection provided by Entity Framework Core.

I recommend that the ObservableHashSet collection change notifications be adjusted so that Replace is only used for a 1 to 1 replacement with NewStartingIndex = OldStartingIndex.

There is a good article explaining the NotifyCollectionChangedEventArgs at http://blog.stephencleary.com/2009/07/interpreting-notifycollectionchangedeve.html

• sjb

[ajcvickers]

Short answer: use ObservableCollection for data binding. It's less efficient, but it preserves order and matches the semantics required by UWP.

[sjb-sjb]

Thanks for your reply. I take your point about ListView requiring an ordering, which hash sets don't have. Having said that, it would make sense to me that navigation sets and ListView work together right out of the box.

Maybe EF could use a combined HashSet and ObservableCollection for this. The hash set would give fast tests for membership while ObservableCollection would enable the use of ListView. The addition or removal of elements would still be reasonably fast given that the ObservableCollection is (I believe) implemented using bit-blitting.

[divega]

From what I remember we decided not to make things more complicated than they needed to be. A more efficient ObservableCollection maybe a general need for UWP/WPF applications.

[sjb-sjb]

Well, I agree the combined data structure is a bit complicated, and not very elegant.

I am not aware of how Contains( entity) is implemented for ObservableCollection, however it would make sense that it map to a firmware operation that searches an array for a bit pattern equal to the pointer to the entity. Theoretically linear time, but in reality very fast. If that is the case then from a performance point of view I would be happy with ObservableCollection as the default and be able to override it to ObservableHashSet if necessary e.g. for a really large collection.

It's a question of how large you think the relationship collections will be in most cases and what they will be used for. Personally my use would be like typically less than 64 and basically listed in UI for a user operation. If the collection is really large then one is probably going to be doing some kind of lazy loading, rather than loading them all via an Include. For example a drill-down type of situation … well in that case it would likely be UI. It's only if you are doing a lot of calculation and no UI that you really need the hash set and don't need the ObservableCollection.

[divega]

@sjb-sjb just to improve my understanding, when you mention the “default”, are you referring to what DbContext scaffolding generates when you point it to an existing database? Or what we instantiate if you make the collection of an interface type?

[ajcvickers]

Marking for re-triage. We could consider:

• Allowing the type we use to be configured
• Making ObservableCollection the default for notification entities, based on the assumption that the most common reason for using them is data binding. However, we don't really have much evidence that this assumption is correct.

[ajcvickers]

Putting this on the backlog to make the type configurable.