-
Notifications
You must be signed in to change notification settings - Fork 67
[Question] - Configuration snapshots #174
Comments
@dazinator did you find out any more information on how to achieve this? I would be really interested as well to implement this (storing settings in database and reload on change via IOptionsSnapshot ) but only if there is a way to reload the settings when changed. |
In 2.0 we changed things so snapshots are scoped and always recreated every request, they no longer have any dependency on reload changes from configuration. You could do something similar as a workaround for now, basically register the existing OptionsManager as a scoped service to use and it will reconfigure a new options instance every request. See c68ede3 |
But if you want to make things work via the current(1.1) design, you will need to register an https://github.com/aspnet/Options/blob/dev/src/Microsoft.Extensions.Options/IOptionsChangeTokenSource.cs which will fire whenever you update |
Perhaps I misunderstand but we don't want to read the value every time, we want it cached until we invalidate the cache. Is this not what the new IOptionsSnapshot provides? Going to database or disk IO on every request even if things haven't changed is not really efficient.. |
Yeah in 1.1 that's how it behaves. In 2.0 we are clarifying the intent, its basically meant to be a snapshot of options for the request. What you describe is definitely the IOptionsMonitor scenario (cache until change is detected). |
@HaoK Thanks for the information. So am i right saying that using the documentation provided in docs - custom provider and the IOptionsMonitor I will be able to reload settings from the database on change and only on change and not every request and have them cached until a change is detected/triggered and this scenario will be supported in V2.0 ? |
Yeah we were considering whether to remove IOptionsMonitor and the related interfaces in 2.0, since IOptionsSnapshot no longer will be consuming them, but if you find the existing behavior is useful irrespective of the snapshot, please add your thoughts to #167 |
Feel free to use #167 if you have any more questions |
From @dazinator on March 8, 2017 14:46
Say I follow the docs and create an EF configuration provider. This means I can update the config values directly in the database table. This question isn't specific to EF though, but more generally about providers that allow their values to be modified at runtime.
My question is, how can I make this provider support
IOptionsSnapshot
mechanism - i.e so that after values are changed in the source (EF table in this case), the existing snapshots can be flagged as outdated so that new snapshots are obtained next time a request is made through DI.I am not asking about how to detect changes made in the table itself. Let's assume that my EF provider offers up an
Update<TOptions>(TOptions options)
method that it will be used to update the values in underlying table for a particular options class when we wish to modify them. In this instance, after the table has been updated, the provider knows exactly whichTOptions
class has had its values changed and so now it needs to make sure new snapshots are created - how does it do that? Couldn't see anything in the docs.Copied from original issue: aspnet/Mvc#5925
The text was updated successfully, but these errors were encountered: