-
Notifications
You must be signed in to change notification settings - Fork 253
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory Store in the chain of stores causes save to fail #29
Comments
I encountered this same problem and traced the same bit through the code. Looking at the
It, of course, does throw an exception ( I was about to fix this and submit a pull request, but I'm not really sure what the intended behavior is here. |
+1 |
In some ways this is similar to issue #20 From the investigation: "When you save your configuration, it does so for all the stores, including the 'system' store, for which saving makes no sense. However, for your 'file' store it works fine. Hence, you see an error but it still saves." The fix quote: "This is fixed in nconf@0.5.0 if you try to save when you have a store which has no .save() or .saveSync() methods, we will not throw an error, we will just ignore it and not save." My preference would be to see the same in the memory store. |
This should be fixed as of PR #38, would you mind testing this @davidcl64 and @jlank? |
Will do - it might take me a bit to get to it, but the provider changes look good. |
Fixed by #38 |
I am currently using a memory store definition passed to child objects to keep readonly semantics on a global configuration file. However, calling save at the provider level results in the following exception:
Using a configuration hierarchy that looks something like:
Calling save on the provider in turn triggers this logic:
The map function triggers saveStoreSync does the following:
resulting in a null instead of the store object when the method saveSync is undefined on a particular store.
When common.merge is then called:
No check is done on the store prior to using it resulting in the exception listed above.
My workaround for now is to monkey patch the memory store with dummy save/saveSync methods.
The text was updated successfully, but these errors were encountered: