BulkUpdate doesn't consider Optimistic Locking

[OculiViridi]

I've opened this dedicated question about Optimistic Locking, from my previous issue (#206).

Looking at SQL generated by BulkUpdate method, it seems that Optimistic Locking is not considered.

Is is possible to add support for it? Maybe with just as a new BulkConfig option?

[OculiViridi]

@borisdj Any update about this question? 😏

[borisdj]

Could you elaborate more on this.
Where can Locking type be configured in regular SaveChanges?

SqlBulkCopyOptions has TableLock if that can be of any help to your case.
Also you could make a Test for the issue you have.

Lib supports attribute [Timestamp] as IsConcurrencyToken.
Example in Test: InsertWithDbComputedColumnsAndOutput (class Document)

[OculiViridi]

Could you elaborate more on this.
Where can Locking type be configured in regular SaveChanges?

SqlBulkCopyOptions has TableLock if that can be of any help to your case.
Also you could make a Test for the issue you have.

Lib supports attribute [Timestamp] as IsConcurrencyToken.
Example in Test: InsertWithDbComputedColumnsAndOutput (class Document)

Yes, I'm speaking about ConcurrencyTokens too. I'm using your library for an UPDATE statement on a table that has 2 ConcurrencyToken specified in EF configuration, like this:

builder.Property(e => e.SelectedAction)
    .IsConcurrencyToken();

builder.Property(e => e.Closed)
    .IsConcurrencyToken();

So, when executing the command with the default EF functionalities, there's the

WHERE [column_previous_values] = [column_last_tracked_value]

clause, added at the end of the UPDATE statement.

Instead, when using BulkUpdate, you can see on the screenshot above, that the "constraint" is not added to the statement, and so there's the possibility (I've made a test) that a concurrency problem happens. That is my question.

[borisdj]

Support added with latest version 3.4.7+
More info in the latest comment on issue #469