[Question] about GrainStorage and the internal VersionStoreGrain

[alirezajm]

I'm writing a storage provider using efcore. The provider works against a configured dbcontext, which means any type being used as storage should have a corresponding DbSet<> on the context. So arbitrary types are not welcomed here, as the backing storage is not happy with them (SQL Server for example).

Now, the problem raises If the provider is used as the default grain storage. This causes the internal VersionStoreGrain to malfunction because of the not configured VersionStoreGrainState. Since the IVersionStoreGrain is an internal interface I can't add another implementation for it (Haven't really thought about if it's a good idea or not).

So to summarize my options:

• Provide another implementation for IVersionStoreGrain, (which is not doable cause everything in there is internal)
• Handle VersionStoreGrainState differently. This probably suggest an internal dbcontext to handle Orleans related stuff. Which also causes the provider to break if I'm missing another internal type.
• Handle arbitrary types using a fallback provider or a key-value table.
• Don't allow the provider to be used as the default storage.

I know using entity framework inherently suggest that arbitrary types can't be used but for this to work it should be able to be used as the only grain storage provider in the silo.

I'll probably go with option 3 with my current knowledge of Orleans. Any advice is very appreciated. I'm gonna open source this as soon as I finish this and write more tests.

[benjaminpetit]

The public interface to implement if you want to implement your own storage for versioning rules is IVersionStore.

I think this is the only built-in grain that requires storage in Orleans.

[alirezajm]

Can you tell me if my understanding of this is correct?

The built-in VersionStore uses the internal VersionStoreGrain and it'll be activated only once in the cluster which makes sense as the whole cluster should follow the same strategy. But doesn't any silo joining the cluster can change the strategy? This causes any deployment to be able to cause undesired effects. Again I have no idea yet who calls for example VersionStore.SetSelectorStrategy, which is declared on IVersionManager.

I also registered a simple IVersionStore implementation and registered it as a singleton, but the runtime didn't use it.

Is there any documentation available about this?

[benjaminpetit]

The built-in VersionStore uses the internal VersionStoreGrain and it'll be activated only once in the cluster which makes sense as the whole cluster should follow the same strategy. But doesn't any silo joining the cluster can change the strategy? This causes any deployment to be able to cause undesired effects. Again I have no idea yet who calls for example VersionStore.SetSelectorStrategy, which is declared on IVersionManager.

Only the management grain is calling tis set method right now. Other silos that join the cluster will read the value from storage at startup, to have a consistent behavior with other silos in the cluster.

I also registered a simple IVersionStore implementation and registered it as a singleton, but the runtime didn't use it.

Yes we might have an issue here, since we do in the silo startup:

services.TryAddSingleton<GrainVersionStore>();
services.AddFromExisting<IVersionStore, GrainVersionStore>();

I will mark this as a bug and will try to fix it for the next 2.1 release

[alirezajm]

@benjaminpetit I think you misquoted the first part of the message.

[benjaminpetit]

Thanks, fixed!

[ReubenBond]

Fixed by #4911