Relationship rework of Version 3 broke support for data classes that use custom implementations of GetHashCode about fastcrud HOT 3 CLOSED

Yikes, that's quite a mess. Don't think that avoiding the call to GetHashCode on the entity instance is the right way to fix this though. I can totally see us forgetting about this edge scenario in the future and breaking it again.

I'm inclined to recommend not using these entities for more than what they are. They should only live in the DAL and mapped to business entities and DTOs for data transmission.

from fastcrud.

Thanks for the acknowledgement.

I actually think that using the EntityInstanceWrapper instead of the Entity itself could solve that issue, especially since the EntityInstanceWrapper implements its own hashcode function that seems to work upon the property values actually read from database - that means the hashcode of the wrapper looks to be very suitable for questions concerning the identity of the wrapped entity. Also since that class is part of Dapper.Fastcrud, you also have complete control over the hash implementation.

To implement that change, the ctor of LocalEntityCollectionKey (as well as the method GetOrAddToLocalCollection of the class TypedEntityContainer) need to be altered to ask for an EntityInstanceWrapper instead of the object instance (or actualInstance).

However there is one case where an instance of MainEntityResultSetParser<TMainEntity> is passed to the GetOrAddToLocalCollection, which obviously is not an EntityInstanceWrapper and it is probably not feasible to just wrap it at that place. That means there has to be an overload or alternative method for this particular case. (Also note that the parser class does not override the hash function provided by the base object type - that implementation is safe to use in the given context)

from fastcrud.

Don't think anyone will take a look at this. As I said, overriding GetHashCode for DB entities is a really bad idea and can cause other issues, especially since these guys could only be partially filled with data at various points. For example, you insert an entity without providing a primary key, which is a great candidate for identifying the entity via Equals and GetHashCode, just to come back later with the identifier filled in by the DB. It's the same entity, however the custom GetHashCode could say otherwise.

I strongly recommend creating a proper set of DTOs for data transmissions and have a set of mappers between the DB entities and your DTOs. That way you won't have any kind of problems and the two layers can evolve independently.

from fastcrud.