Upsert on IQueryable<Entity>

[Kalshu]

In my case, i want to make an upsert in place of ExecuteUpdateAsync (only usable for an update

await _dbContext.dbSet1
    .Include(d=> d.W
        .Where(cw => cw.Id == wInstance.Id))
    .Where(d=>d.Id == cdId)
    .SelectMany(d => d.W
        .SelectMany(cw => cw.OW)
        .Where(cw => cw.UserId == currentUser.Id))
    .ExecuteUpdateAsync(update => update
        .SetProperty(cw => cw.prop1, widgetInstance.prop4)
        .SetProperty(cw => cw.prop2, widgetInstance.prop4)
        .SetProperty(cw => cw.prop3, widgetInstance.prop4)
        .SetProperty(cw => cw.prop4, widgetInstance.prop4)
    );

But the return of the SelectMany is an IQueryable of an entity.

Is there any plan to support upsert on a different object than DbContext?

[JimHume]

I have a similar request (or question, really).
My model builder adds HasQueryFilter(item => !item.IsDeleted) (e.g.) logic during the OnModelCreating method of the context itself.

I would like to ignore the query filters when upserting but it doesn't seem possible to do this. I could be missing something fundamental / obvious, but I can't seem to find anything related to IgnoreQueryFilter or HasQueryFilter with FlexLabs.

For posterity: the factory which creates/resolves the DbContext can be overridden and new parameters added to the constructor of the DbContext so that the adding of HasQueryFilter is optional, but this seems like an awkward workaround for a very specific / isolated issue.

[artiomchi]

@Kalshu - I don't think I'd be able to easily support running upserts on an IQueryable. I need the reference to either the DbContext or the DbSet to be able to get the table metadata, so that I can generate the SQL statements that execute the upsert call. IQueryable of an entity is also a non realised collection, and even if it was an input to the upsert command, I'd have to load it all into memory to be able to generate the query.

[artiomchi]

@JimHume your situation seems pretty different, but interesting.. Unfortunately my day to day work doesn't require EF Core use these days, so I don't have as much experience with this