Grains directly interacting with storage
The storage provider plugin model follows the pattern of loading the state at the time of activation. IPersistentState will be injected into the grain through the constructor. The state will be loaded before the OnActivateAsync method. The state will be persisted back to the storage provider by calling WriteStateAsync and can be refreshed at any time by calling the ReadStateAsync method. But this model may not work for all scenarios. In this section, we will see the scenarios that require the grain to access the database directly and ways to achieve that.
Consider the scenario where the write operation demands to call a stored procedure in the Cosmos DB provider, or we need to run a custom query to load the state on an ADO.NET provider. Both these functionalities may not be supported by the existing storage provider. In addition to this, having all that data as part of the grain state and loading it at the time of activation may be overkill...
