Merge/Upsert/AddOrUpdate support

[NickAb]

In my project I need to insert entity if it does not exist yet, or update it otherwise (somewhat like UPSERT in mongodb). As I understand in SQL it can be accomplished using MERGE, but I was not able to find MERGE in EF Core.

[gdoron]

@NickAb I'm not sure Merge is even applicable to ORMs.
Can you write a little snippet showing how you would have use it?

[rowanmiller]

There isn't anything at the moment, though we could potentially do something nice (but not for 1.0.0).

[NickAb]

@gdoron Actually, I am only interested in merge-as-upsert analog (upsert as in mongo upsert), not full-blown MERGE syntax, so it might look like:

var newFeatureForRegionSetting = new FeatureForRegionSetting();
entity.Region = region;
entity.Feature = feature;
entity.Settings = settings;

dbCtx. FeatureForRegionSettings.Upsert(x => x.region == entity.region && x.feature == entity.feature, newFeatureForRegionSetting);

which will insert newFeatureForRegionSetting if condition is not matched, or update entity if condition is matched.

I can not provide usage example for full-blown merge, as I am not that familiar with other MERGE uses.

[philn5d]

Is it the same feature as this?

[NickAb]

No, I don't think so. As I understand, the issue you are referring to is about "merging disconnected graphs", so it is about interworking of EF change tracking, etc.
What I am referring to is SQL MERGE statement, see docs here https://msdn.microsoft.com/en-us/library/bb510625.aspx

[philn5d]

Ah, I've done this with a home brewed extension method but it needs to get the entity before doing the upsert. Needed to define the key value and didn't support multiple keys. Would be useful to have since it would be more performant.

There's a pattern described https://msdn.microsoft.com/en-us/data/jj592676.aspx
Which is essentially what I wrapped in the extension, would be much better if the framework did this instead. Especially if it can be made to determine if the keys are default or not - without necessarily loading the entity from the data store.

Perhaps it could leverage the MERGE statement as you alluded to. Match on entity keys. I could see folks wanting the results of the MERGE returned which would complicate the operation. The simple case would be useful enough to warrant only Insert or Update with no additional complexity. Also, depends on whether or not the data store supports MERGE if its to be used to implement the feature.

[Ciantic]

There is a very handy document in PostgreSQL wiki about UPSERT in various SQL dialects. It may come handy if someone is trying to implement it in the EF.

(In practice it seems there is no agreed way how it should work, especially with unique fields, and would be a messy thing to do in EF because of it)

[yosbeleg89]

This is an implementation of MERGE to MSSQL than can give ideas. It is an extension method to EF6.

[PeteX]

I know there are lots of things it would be nice to support, and limited developer time, but it's a shame this one is missing. Apart from this, my code is entirely database-independent, but it's hard to implement upsert without database support.

The usual pattern is that you try to insert, and whether it succeeds or fails, you know the relevant row is in the database. You can therefore pull it out and work with it. There are problems with this approach, though:

• As far as I can tell, you have to discard the DbContext after the insert fails, because otherwise the next SaveChanges() will retry the insert.
• EF Core seems to write an unwanted exception message into the log when the insert fails.
• Failure usually aborts transactions, so the insert attempt and the following update can't be atomic. This creates problems with races where the insert succeeds, but the row gets updated before the following update.

[roji]

Just pinging this to make sure it's not totally forgotten. With the seemingly wide support of UPSERT/MERGE across databases, this could be a pretty valuable feature (although of course the specific implementations/variations would have to be investigated (see this comparative doc cited above by @Ciantic)

[ajcvickers]

@roji Thanks--there's definitely a lot of value in doing this. the comparative doc is very useful--we would have to figure out what to do for SQL Server.