Async Support for Individuals

[OnurGumus]

SQLProvider’s Individuals feature currently blocks the thread at runtime. While synchronous behavior is needed at compile-time, adding async support at runtime would improve consistency with modern async APIs.

Even if the performance gain is minor, it would help avoid blocking in async workflows and align better with typical .NET usage.

[Thorium]

Sound good suggestion. What should the user code look like?

[OnurGumus]

Perhaps something like:

async{

let! res = customers.IndividualsAsync.COMMI
...

} 

[Thorium]

Sounds good to me (except task instead of async).

[Thorium]

The problem I have with the current individuals feature is that it potentially performs a large database query at design time, and if you use an offline schema, the schema file also grows big, so it's slow. To be efficient, individuals-count has to be limited aggressively, but limiting it too much will take away some of the benefits of the feature.

What is your use case for individuals? Where do you need them at runtime? Are you using them on a small table (like let's say "give me enum options like units of measures")? Or like some pre-defined constant data?

[Thorium]

The list of individuals are read from the concurrent dictionary at compile-time/design-time and maybe at the beginning of the program, but then the queries are not actually hitting the database but rather only read from memory.

The real executed query is used with GetIndividual-method which only returns the single individual by id (primary key?) thus it should not be taking a long time, so the benefit of async may be limited.

[OnurGumus]

Even if a single query is fast, imagine running it in a loop or across 100 threads concurrently. Making it asynchronous can still offer significant benefits. It also follows the principle that all I/O operations should be asynchronous whenever possible.