Add/Edit but not Delete

[evanjehl]

Is it possible to override the behavior of EqualityComparison so that items in the destination collection are not deleted if they don't meet the comparison? In other words, the mapper would add records from the source collection that don't exist in the destination collection and edit matching records in the destination collection, but not delete any records in the destination collection. I am thinking about a scenario where I am only submitting the "dirty" elements from a list in a model and then mapping the model onto an EF entity.

[TylerCarlson1]

If you do that then it's not longer a collection mapping it's an update already existing items mapping, which is completely different from both AM and AM.Collection work.

You can use AM.Collection as base and copy EquivalentExpressionAddRemoveCollectionMapper and edit to not Remove items, then you can have your functionality. Add to object mappers instead of the other implementation and it will get the job done. But this wouldn't be added to AM.Collection because it breaks core functionality.

[Nils-Berghs]

I had the exact same question, from my point of view It makes perfect sence to do that, after al you are mapping to an existing list. (suppose you need to combine data from two databases, map from database one to business objects, than map from database two to the existing business units).

Anyway modifying EquivalentExpressionAddRemoveCollectionMapper seems hard to maintain. So I have created a simple work around using a list that doesn't support removing items (but lets you believe it does). See this topic on SO for the full explenation.

[vratojr]

@TylerCarlson1 what about a solution like this:

we could create a class like:

IRemoveHandler(){
 void Remove(TDestination destination,TDestinationItem itemToRemove);
}

and provide the default implementation that does: destination.Remove(itemToRemove).

Then, in EquivalentExpressionAddRemoveCollectionMapper we could inject the Handler and change:

destination.Remove(removedItem); to this.removeHandler.Remove(destination,removedItem);

And then, when configuring the mapper, we could pass our specific implementation of the RemoveHandler. This would not break any core behavior but still solve this problem and also that of having a soft delete like proposed in PR #21 . Also would fix #32 and #60 What do you think?

[TylerCarlson1]

Pull Requests are always welcome. I would just not want to break the existing API, so no remove handler defined should keep default functionality.

[cesarsouza]

+1 for adding this. It would also make it easier to implement soft-deletes, right?

[lpgoncalves]

+1 for easy soft-deletes support

[schhwork]

I was trying to use this today, and its a pretty common scenario that you only have added and changed object in your sourcecollection, in my case i map between two databases and send source collection through an API, i only send added or updated entities as i never delete anything in my source db, i dotn see how adding a possiblility to configure how the mapping behaves breaks the core functionality.