Skip to content

demonstrates HashSet inconsistency when used with ef core

Notifications You must be signed in to change notification settings

mhDuke/efHashsetIssue

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

6 Commits
 
 
 
 
 
 
 
 
 
 

Repository files navigation

two almost identical entities VehicleInitialized and Vehicle. they own a collection of Feature, in the form of private HashSet. Worth to mention that the Feature type overrides Equals() and using Feature.Id for equality comparison.

VehicleInitialized has the HashSet initialized at declaration: private HashSet<Feature> _features = new HashSet<Feature>(); but Vehicle entity however, has its HashSet<Feature> _features; initialized only in a public constructor with parameters, that is not used by ef core.

both entities are tracked by HashsetContext.

when pulling a saved instance of VehicleInitialized off the HashsetContext, and attempting to add features that are already added before persisting the entity won't do anything. HashSet.Add() will return false. on the other hand, when doing same thing with Vehicle entity, will add the duplicate features and return true.

the reason is ef core will initialize a hashSet with reference equality, hence the overriden Equals() will be ignore. now obviously the work around is to manually instantiate the HashSet at declare, with potential ef core malfunction, and losing the protection advantage of not initializing collections in declaration as advocated by jon p smith and i qoute:

I purposely don’t initialise the _reviews field in the private parameterless constructor that EF Core uses when loading the entity.

of course the better approach is to use a List implementation and maintain the no-duplicates-allowed logic manually.

About

demonstrates HashSet inconsistency when used with ef core

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages