Add Async Query Support

[Turnerj]

Closes #26

Add support for async queries, specifically async versions of these:

• First/FirstOrDefault
• Single/SingleOrDefault
• ToList
• ToArray
• Any
• Count
• Max
• Min
• Sum

Additionally, support IAsyncEnumerable<T> via AsAsyncEnumerable.

Each item in the list above needs custom handling to inject the right expression into the MongoDB driver while also triggering the async execution path on the MongoQueryProvider. If you simply call AsAsyncEnumerable().FirstOrDefaultAsync(), that will not filter the query properly and will make the DB return more than one item (as it batches items internally). Similarly, if you ran AsAsyncEnumerable().SumAsync(), it would return all of the items from the DB and do the sum locally. Fundamentally this problem exists as there is no such thing as an async Queryable and all enumerables are performed locally.

The effort involved in supporting this process makes it possible to side step the built-in result transformer logic of the MongoDB driver which is a good thing for MongoFramework as the only way to call it was via reflection (it is an internal type we need access to).

This will have full support for .NET Standard 2.0.

Original Description

This adds IAsyncEnumerable<TOutput> support to MongoFramework, allowing for full async/await paths.

Support will likely be shaped around Ix.NET though will likely need to factor in the same issues that EF Core have had.

The ideal end result is full backwards compatibility for IAsyncEnumerable even where it isn't available as standard (.NET Standard 2.0). If this is not possible, async query support will be limited to .NET Standard 2.1 and above.

[JohnCampionJr]

Curious as to what needs to be done to get this merged (beyond updating the branch to the latest). The code seems to work well. Happy to help!

[Turnerj]

I'm curious too - I don't remember why I didn't merge it. I think there was something weird with extensions on IEnumerable<T> and IAsyncEnumerable<T>, potentially conflicting? Wish I wrote notes down!

Probably will need to add a few more tests at minimum as I know I had some issues previously with wrapping the "Result Transformer" on the sync-path, probably have the same issue on the async-path.

I'll give it a look again - maybe today - and see what is actually left.

[Turnerj]

I worked out why I didn't merge the change, it only added async support for enumerating, not for FirstOrDefault, Count etc. The reason the distinction is important is that when you call AsAsyncEnumerable, it has actually started the query to the DB so if you did myQueryable.AsAsyncEnumerable().CountAsync(), that count would be done locally (async fetching all the entities then counting it), not on the DB.

I need to manually add every async extension myself on IQueryable like Entity Framework does.

I'll add a few big ones and add the rest ad-hoc:

• FirstAsync (with and without expression)
• FirstOrDefaultAsync (with and without expression)
• SingleAsync (with and without expression)
• SingleOrDefaultAsync (with and without expression)
• ToListAsync
• ToArrayAsync
• AnyAsync (with and without expression)
• CountAsync (with and without expression)

Any others after that should be fairly simple PRs just following the same pattern.

[Turnerj]

Maybe not as simple as I was hoping - the result transformer logic for async in the driver is different from sync. Specifically for sync, it uses the Enumerable extension methods, taking an IEnumerable in. For async, it is expecting to take an IAsyncCursor which I don't have because of how I need to intercept the logic. Instead I have an IAsyncEnumerable.

All in all, I basically need to make my own result transformers but that isn't actually too bad as I might end up avoiding some reflection logic.

[JohnCampionJr]

I spent a chunk of time yesterday trying to understand the internals of the Async support. I got as far as the ResultTransformer and I understand what you're doing with the First, but have no idea how to help implement more. Sorry....

[Turnerj]

No worries - I think I have a good strategy for the different methods etc now. Also learnt that the MongoDB driver doesn't support Last or LastOrDefault which is fine for me - I never use them myself plus I can remove a bunch of code from my new async path.

[Turnerj]

What is left is AnyAsync (shouldn't be too bad) and SumAsync (shouldn't be hard, there are just a lot of variations to test due to how the Queryable works).

[JohnCampionJr]

Small change suggested, discovered when building DbSet tests for MultiTenant

In QueryableAsyncExtensions.cs, two spots

	//if (source is IMongoFrameworkQueryable)
	if (source.Provider is IMongoFrameworkQueryProvider)

This change allows the extensions to run on the DbSet directly. No tests broke with this change.

[Turnerj]

Good idea @JohnCampionJr !