-
-
Notifications
You must be signed in to change notification settings - Fork 10.6k
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
Refactored to save settings only if value changes #9194
Conversation
refs TryGhost#9192 - Each setting is saved individually - Update this to only happen on import, or when a value changes - Reduces the amount of work Ghost does on every setting change
@kirrg001 & @kevinansfield I have tested this and it seems to work well. Just wanted to quickly check - can either of you think of anything this might break? That's all I want review for 😄 |
Nothing that I can think of 🤔 Sounds like a sane change to me! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using settings.set
allows us to use hasChanged
, makes perfectly sense 👍 Good improvement.
I just added one comment.
core/server/models/settings.js
Outdated
} | ||
|
||
if (setting.hasChanged()) { | ||
return setting.save(options); |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
@kirrg001 good catch, pushed a fix |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Feel free to self merge if travis is green!
This is quite a small change, but with potentially larger consequences. At the moment, requests from the Ghost Admin come into the settings endpoint with multiple settings to update. There's no guarantee any of them have changed.
On the server side, we blindly processed all the settings, saving each one with the "new" value regardless of whether anything changed. The updated_at value will change every time.
The code in this PR changes this to be smarter. We set relevant properties on the model and then if bookshelf's
hasChanged
method tells us any of the values are different, we save, else we just return.The benefit is less events flying through the settingsCache system. My end goal here related to #9192 is to know when a setting is really changed to check if a route like
/subscribers/
or/amp/
should be enabled or not.refs #9192