CancellationToken support?

[jakejscott]

Hey ya, do you have any plans to support CancellationToken's?

[mikependon]

Hi @jakejscott , actually no. But, I really would like to if you can share me the detailed explanation and which scenario. Can you expand this thread to let me understand it further?

[SergerGood]

@mikependon why not? This is necessary to cancel long-running operations (like batch insert). There must be a way to stop an operation that is no longer needed. Or you will have to wait for its end.

[mikependon]

TBH, I know this is quite needed in some cases, but such request has not been triggered after this. The user closes the request ticket without providing enough information. Happy to reopen this if you can provide same samples, scenarios and/or recommendations.

Also, I think I need to spend time researching what happened to the DB Provider side if the operation has been executed already, but a cancel has been requested.

[mikependon]

This could be related to this dotnet/runtime story.

[mikependon]

@jakejscott @SergerGood - I can easily add the CancellationToken on the Async methods, however, how would you like to handle the sync version?

Remember, you do not have access to the DbCommand object in all kinds of execution within RepoDB, therefore, you cannot call the DbCommand.Cancel() method. Of course, unless we place it to the ClassHandler (#530) object and/or provide a callback function calls.

What's your preference?

[SergerGood]

It will be like this for example 5580088
And the use is like this

        public async Task<List<Person>> Query(CancellationToken cancellationToken)
        {
            using IDbConnection connection = await new SqlConnection(ConnectionString)
                .EnsureOpenAsync(cancellationToken);

            return await connection.QueryAsync<Person>(x => x.Id == CurrentId, cancellationToken: cancellationToken);
        }

[mikependon]

@SergerGood - I am actually doing this one already, but it is only for Async. How about the sync version? How would you do that as we do not have reference to the DbCommand.Cancel().

[SergerGood]

I have not seen use of undo for synchronous operations when working with DbCommand...

[SergerGood]

May i ask why not used default?

[mikependon]

I think to force it to be nullable instead for the reason of overloaded methods. There might be case that the user will never ever pass a value to it, and placing a default would force the execution to an overloaded method of the underlying DbCommand.

I used to do it this way.

using (var reader = cancellationToken.HasValue ? await command.ExecuteReaderAsync(cancellationToken.Value) : await command.ExecuteReaderAsync())
{
     ...
}

And by having a default, would force it to the await command.ExecuteReaderAsync(cancellationToken), in which the value of the cancellationToken is the CancellationToken.None. I guess it should not be like that?

[SergerGood]

CancellationToken.None is the default way to pass empty CancellationToken.
If CancellationToken.None used then that is, its CanBeCanceled property is false. https://github.com/microsoft/referencesource/blob/f461f1986ca4027720656a0c77bede9963e20b7e/System.Data/System/Data/Common/DBCommand.cs#L250 The user does not need to pass a value by default, and the behavior is handled correctly.

[mikependon]

Yeah, in such a case, you can always pass it on the nullabe argument right? The behavior is to make sure not affecting as well all the previous implementations.

[SergerGood]

If used as a parameter with a default value, it has no effect for all the previous implementations.

..., CancellationToken cancellationToken = default)

[mikependon]

@SergerGood - you are correct on pushing this, they are passing the default value here. Great sleuthing!

[mikependon]

Relating the recent found bugs at #601.

[mikependon]

@SergerGood - I have to remove the explicit calls you made for cancellationToken.ThrowIfCancellationRequested();. Let us just pass it and have RepoDB bubble ups the exception thrown by ADO.NET itself. Hope it is okay.

[SergerGood]

@mikependon - I think that it is ok)

[mikependon]

@SergerGood - I am done with the changes, but we have some failing Unit and Integration Tests. Will work on this soon. In the meanwhile, would you be able to do a double check while I am fixing the failing tests? Thanks

[mikependon]

This is now available at RepoDB v1.12.4. Please see the actual release here.

[mikependon]

Setting this one to close now.