orleans
orleans copied to clipboard
dotnet
ADO.NET Refactoring
This is a first pass at refactoring the ADO.NET provider projects.
This pass focuses on freeing the code from the compiler directives in linked files, while moving common code to a core project.
This core project is still tightly coupled with the other ADO.NET projects as of now.
There is no effort yet to integrate with DI, that's left for a second pass.
While this PR is very intrusive, it is not meant to have any breaking changes.
Microsoft Reviewers: Open in CodeFlow
Hey, @JorgeCandeias looks good! I'm all good for removing the pragmas and modernizing the C#.
One thing to note is that if you prefer, for instance e.g. https://github.com/dotnet/orleans/pull/9024/files#diff-454dbc7924a5a6ce62641db0fd5bc4429ec52a78c0e63f44b6c3b0e7b156541e could be basically the queries in a dictionary. I mention this since then it likely would be easier to actually supply them through options e.g. in startup or later do differently altogether (this was the original way).
@veikkoeeva Thanks for reviewing! Moving the query keys to an options class is on the list for the next PR, along with moving services to DI. In addition, the ability to specify the full schema/name for the queries table itself needs to be added. Let's do one thing at a time so the PRs are easier to review.
@veikkoeeva Thanks for reviewing! Moving the query keys to an options class is on the list for the next PR, along with moving services to DI. In addition, the ability to specify the full schema/name for the queries table itself needs to be added. Let's do one thing at a time so the PRs are easier to review.
Sounds like a plan. To give a bit of history (this has been also in Gitter and now Discord, but a few words here too): It could be useful to be able to change queries or even storage layout if data traffic patterns or storage and processing changes. As in getting more data or more I/O capacity on the fly and if its possible to react without downtime. So consequently, not only bring things like this into startup options but to the DI to be changed on the fly. Some industrial and other uses cases are a bit hard to run down and preferably one can avoid that to fix or change things. This hasn't been the Orleans focus but might be useful to know.
It could be useful to be able to change queries or even storage layout if data traffic patterns or storage and processing changes.
We can start by making the query entries configurable via some options class. Later on we can expose some interface to allow the user to bypass the fixed-signature query stuff altogether. The reason is that each database engine can provide specific features that can better implement streaming, yet conflict with the polling design. For example, SQL Server provides the Service Broker, which is more appropriate to real-time streaming than the current table based implementation. However its blocking nature conflicts with the fast polling nature of the generic polling agents. So something needs to give along the way. It's a challenge to abstract and specialize at the same time.
As in getting more data or more I/O capacity on the fly and if its possible to react without downtime. So consequently, not only bring things like this into startup options but to the DI to be changed on the fly.
Got a feeling IOptionsMonitor<T> and some forever loops will be our long term friends.
Some industrial and other uses cases are a bit hard to run down and preferably one can avoid that to fix or change things.
Can you elaborate?
@JorgeCandeias
Some industrial and other uses cases are a bit hard to run down and preferably one can avoid that to fix or change things.
Can you elaborate?
Factory systems (consider 24/7, with e.g. yearly maintenance window of a day), large scale logistics systems and some payment systems are my experience. One can plan for it, better if it were possible to be able to change things on the fly.
As an aside:
For example, SQL Server provides the Service Broker,
Is this still dog slow? Though a good example, or the PostgreSQL extensions.
Closing this inactive PR to open the way for the Grain Directory one.
I need to spend some more time with the current ADO.NET bits. Ideally, I would like to see how we can simplify it. Perhaps all DBs can use asynchronous IO now, for example, allowing us to delete some paths
Honestly, I wouldn't bother. The best thing we could do would be to rip apart this "adonet" family into separate, specialized packages for each database technology. RDBMs now vary wildly in capability since when these packages were first created. The RelationalOrleansQueries abstraction now stands more in the way of making the best use of each technology than helping using it.