Skip to content
This repository has been archived by the owner on Nov 7, 2018. It is now read-only.

[Question] - Configuration snapshots #174

Closed
Eilon opened this issue Mar 9, 2017 · 8 comments
Closed

[Question] - Configuration snapshots #174

Eilon opened this issue Mar 9, 2017 · 8 comments
Labels

Comments

@Eilon
Copy link
Member

Eilon commented Mar 9, 2017

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 which TOptions 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

@flatproject
Copy link

@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.

@HaoK
Copy link
Member

HaoK commented Mar 15, 2017

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

@HaoK
Copy link
Member

HaoK commented Mar 15, 2017

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

@dazinator
Copy link

dazinator commented Mar 15, 2017

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..

@HaoK
Copy link
Member

HaoK commented Mar 15, 2017

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).

@flatproject
Copy link

@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 ?

@HaoK
Copy link
Member

HaoK commented Mar 16, 2017

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

@HaoK
Copy link
Member

HaoK commented Mar 19, 2017

Feel free to use #167 if you have any more questions

@HaoK HaoK closed this as completed Mar 19, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants