You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, if new field is added to the config of once of components of the node it requires manual bump of the config. It is not the best UX experience. Node runner can simply forget to do it, which could lead to node behaving unexpectedly. I want to suggest to add file with versions of stored objects, that might need migration. It will allow auto-bumps and migrations strategies.
Examples of versioned stored objects:
config
blocks data
Simple changes to config / storage could be tracked by node app. On startup node can check if stored version < expected by binary. Then it can execute different migration stratagies depending on results. For example for config it can be:
minor update. Should be used for easy to auto-update changes. Keep all previously values and merge in new ones.
major update. Notify user, that new config is not compatible with old one. Might suggest few options, like :
exit node
overwrite config with new generated default one
Current state of config update just gives a lot of pain for users after any release that touches config.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Currently, if new field is added to the config of once of components of the node it requires manual bump of the config. It is not the best UX experience. Node runner can simply forget to do it, which could lead to node behaving unexpectedly. I want to suggest to add file with versions of stored objects, that might need migration. It will allow auto-bumps and migrations strategies.
Examples of versioned stored objects:
Simple changes to config / storage could be tracked by node app. On startup node can check if stored version < expected by binary. Then it can execute different migration stratagies depending on results. For example for config it can be:
Current state of config update just gives a lot of pain for users after any release that touches config.
Beta Was this translation helpful? Give feedback.
All reactions