Bug: Async fetch operations are not using the DbDataReader.ReadAsync method (in v1.12.0 to v1.12.2)

[mikependon]

Affected by the latest release and core compiler updates, the current fetch operations are not using the DbDataReader.ReadAsync() operations. All the Async fetch operations (i.e.: BatchQueryAsync, QueryAsync and ExecuteQueryAsync) are using this sync method.

[mikependon]

We are aware of this and is currently working on the solution. This will be a part of the next release.

[mikependon]

The fix is now deployed and is available at RepoDb v1.12.3.

[BieleckiLtd]

Hi. I was looking to fill similar ticket but since you were faster I will ask question part of my issue :) I am looking at private static async Task<IEnumerable<TResult>> ExecuteQueryAsyncInternalForType<TResult> and can't figure out what is the purpose of AsList() in var result = (await DataReader.ToEnumerableAsync<TResult>(reader, dbFields, connection.GetDbSetting())).AsList(); Because of this you later have to do casting (IEnumerable<TResult>)result which otherwise could be avoided I'd guess.

[mikependon]

You are correct, this is a valid question to the ToEnumerableAsync() method as the resultset is actually a List<TResult>, we are not using IAsyncEnumerable<TResult> there (meaning, no yielding). However, the AsList() is casting it back to the correct type, and no conversion is happening. The impact is very minimal. I hope you that explained.

[BieleckiLtd]

Yeah, ok, thanks. I think I was associating degraded async performance of larger data sets with that casting and type conversions, but after I updated to 1.12.3 it's returning my data blazing fast nonetheless.

[mikependon]

Remember, there is no conversion there. It is only casting it, but to make it perfect, you are correct that the mentioned AsList() call is not necesarry. I am happy if you could PR that :)

[mikependon]

This has been fixed and is now available at RepoDb v1.12.3. Closing this incident ticket now.