Use Async in Windows Preview Blog Post Examples about rethinkdb.driver HOT 5 CLOSED

Hi @tmds,

Thank you for bringing up your concerns. I wasn't involved in writing the blog post or writing the examples. I caught wind of the announcement through social media.

I noticed there were some issues with the examples also. I tried to get them corrected as fast as possible. See: rethinkdb/aspnet-signalr-chat#1 The initial PR doesn't make the examples fully async, but it resolved issues that I thought were most important regarding usage.

Overall, I think the main purpose of the blog post was to keep the examples as simple as possible.

I've added a ChatHubAsync example in a 2nd PR: rethinkdb/aspnet-signalr-chat#2

Please feel free to make continued improvements on it. It would probably be best if you worked with the RethinkDB team directly via @segphault (aka rkpaul on slack). I am not part of the RethinkDB team, so there isn't much I can do to help resolve your issue regarding the blog post or examples.

from rethinkdb.driver.

Thanks for your feedback.
What's your view on leaving out the non-async API from the library?

from rethinkdb.driver.

Hi @tmds ,

I haven't fully completed the async API implementation yet. The last thing I need to do for async is properly implement CancellationToken mechanism.

Much of the effort has been:

1. Reach API and feature parity with the official Java driver.
2. Extend ReQL expressiveness in C#.
3. Re-work the driver connection architecture to make it thread-safe and usable in apps. The threading architecture in the .NET driver is currently being back-ported to the Java driver.
4. Getting the full battery of unit tests to pass on Windows RethinkDB Server.

I totally understand your motivation for removing non-async API. The future is async in .NET, but I'm hesitant on removing the non-async API from the driver. Here are my thoughts:

• It forces developers to use async - I'm hesitant forcing developers to use particular sync/async calling convention. I think giving devs a choice is good.
• Convenience - A lot of value can come from convenience. Sometimes writing a simple C# app / demo to get up and running fast without any hassle is really good. There are times were devs don't want to be bothered with async, even if it's not the most efficient.
• Proper async is easy get wrong - Most commonly, async void, ConfigureAwait, among others. TBH, having not used it in a while, I got it wrong a few times too... and I think it would only perpetuate these issues.
• Unit tests - Currently, over 1,500+ imported YAML unit test batteries are designed to run synchronously. It would only complicate the import process, impose additional maintenance and complexity when updating unit tests.

I hope you find these reasons acceptable.

from rethinkdb.driver.

I think it is good when libraries force developers to adopt modern coding practices.
If a developer still wants blocking calls, he/she can call 'Wait' on the Tasks.

For your unit tests, perhaps you can make the non-async API internal and use the InternalsVisibleToAttribute so the unit tests can still access it?

I will only be using the async methods of this library and I'll frown upon everyone who doesn't ;)

Thanks for the library! Especially the async API!

from rethinkdb.driver.

Hey, no problem. Thanks for giving the driver a try. I really appreciate your input.

After thinking about it a bit more, there could be a possibility of lifting all the non-async API off the core API and move non-async APIs into extension methods. Kind of best of both worlds, but this would be a lot of work right now. My main focus is helping AtnNn to get all unit tests to pass on the windows preview. Currently, they all pass on Linux RethinkDB Server, but fail on Windows RethinkDB Server.

Edit: Now using .NET/C# naming conventions! :)

from rethinkdb.driver.