Async direct Database connection?

Unity Engine
1

I’m building real time RPG game, I don’t want to use any external services that the C# application (so using some PHP or whatever server language to connect DB isn’t available). Also, it’ll be awesome if it runs asnyc in a separate thread/process so it won’t affect the main Unity server.
So in short, I want to have a class that has CRUD operations for the DB, but doesn’t run on Unity main thread and doesn’t use external web services to query DB.

Any ideas how to achieve that??

2

You may use async/await concept in 2007.1 to execute operations asyncronously AFAIK. There should be sync context in the main thread in the new Unity version. Also .NET database access componets have means to execute queries in async manner, check out this article: Performing Asynchronous Data Access | Microsoft Learn

But generally speaking, you’re putting your application API layer from normal scheme like APP > API > DB in the application itself. The following disadvantages arise.

  • It becomes impossible create different apps using the same API on server, you need to build API in each app. For example, no way to create website showing player stats by just calling API method and applying and html/css template to the data returned, it will require to integrate db queries into web page or create another PHP or node.js API just for this purpose.
  • The database is exposed to hackers attack as it becomes directly available over the network, not protected from malicious users by the API logic, standard popular schoolboy exploits may work if you don’t hire a higher level pro DBA.
  • The logic of the API and storage structure and data queries are delivered to the end user, making it super-easy to decompile game back to the C# or JS and create clones in almost no time.
3

I’m not really familiar with the old Begin/End concepts, isn’t there something more of Thread/Action/Task stuff?? Also, is it possible to use Entity Framework or some other ORM? raw SQL isn’t really my thing.
The reason I don’t want to build some web API for my app is to avoid the overhead of connecting to local server DB and querying that application, also to reducing coding time.
As for the disadvantages:
1-I don’t intend to have any other app using the API, currently it’s only for in-game stuff. If at a later time I decide to allow some web stats, I’ll simply build another app that connects to same database but with different rights.
2-Clients won’t have the DB code, I have separate projects for client-server (have a work around for UNet to work) so clients will only be using Commands/NetMessages to communicate with server, while the server does DB stuff. So for the client, there’s no way for them to know what’s going on DB side.
3-Same as 2.

4

Modern technology I mentioned at start. It’s async/await concept you may use in new unity version. With this approach any operation, db queries or else, may be performed in asynchronous manner. Check out this article at MSDN - Asynchronous Programming with Async and Await (C# and Visual Basic) | Microsoft Learn

5

Which version exactly adds support for Task and async/await ?? I’m pretty familiar with Tasks due to web dev and DB querying.

6

I’ve just tried writing an async test methodpublic async Task test(){return Task.Delay(100);}However it doesn’t seem to compile, mono is missing Task and complaining about not finding types.

Is there some stuff I need to add/reference before being able to do that??

7

May be adding

using System.Threading.Tasks;

to the usings section will do the trick?

8

When I try that I get “error CS1644: Feature `asynchronous functions’ cannot be used because it is not part of the C# 4.0 language specification”
And project won’t run.

9

This should work since 5.5

But actually I can’t see those choices in 5.6 I use.
Anyone?

10

Also this may help
https://bitbucket.org/alexzzzz/unity-c-5.0-and-6.0-integration/src

11

I’m using Unity 5.6 too, and the thread says it’s for 5.5… won’t it break anything if I use it there??
Also, I’ve tried that C#7 support, still didn’t work.