Settings migration after a Schema rename

Hello, I need to rename the GSettings Schema ID for an extension that I maintain (gnome-shell-system-monitor-applet) since it clashes with a standard gnome-shell extension (gnome-shell-extension-system-monitor) as well as the original version of the extension (mine is a fork).

The issue is that I don’t want users of the extension to lose their existing settings, so there needs to be some kind of settings migration that takes place for users who upgrade the extension and get the new Schema ID.

The initial approach I took for solving the problem was to ship two XML Schema definition files: one with the old ID and another with the new ID. Then during extension start-up I read in the old settings (with a call to getSettings(oldSchemaId)) and copy over everything from the old settings to the new settings (see the implementation here). My plan was to delete the old definition file after a few months or so once the majority of users have upgraded.

This seems to be working well but was rejected in review due to this item of the EGO Review Guidelines regarding GSettings Schemas:

  • The Schema XML filename MUST follow pattern of <schema-id>.gschema.xml.

Does anyone have any suggestions for alternative solutions to this problem (settings migration due to Schema ID rename)? I know I could probably ask users to run some variant of dconf dump | dconf load, but ideally I’d like this to happen without user intervention.

1 Like

Did you explain your use case and rationale for shipping both schemas to the reviewer?

I faced the same issue several years ago, and I found that GSettings migration or doing refactorings to the schema is difficult to achieve if we want to keep users’ settings.

My solution was to use the dconf library, like you suggest.

A small utility, but in C: src/gtex/dh-dconf-migration.h · main · Sébastien Wilmet / enter-tex · GitLab

If you use the GSettings API instead, it works with schemas, so the old schema must be installed, which is not good if two different modules want to install the same schema.

IMHO, a better support of settings migration would be useful as a first-class citizen in GIO. To have something that works with all GSettings backends.

1 Like
  1. You should remove the version (.v0 and .v1) from the xml filename to make it EGO compatible. That’s why it got rejected. You can use two xml files in the schemas folder:

    • org.gnome.shell.extensions.system-monitor-next-applet.gschema.xml (for the new id)
    • org.gnome.shell.extensions.system-monitor (for the old id)
  2. Don’t forget to include the migration related files as missed in the EGO package:

    • utils.js
    • migration.js
1 Like

Guh, I think you’re right, @jrahmatzadeh… I should have noticed that… I’m going to try re-submitting with the corrected filenames and see how it goes.

Thanks to everyone who replied, I’ll update after the next round trip to EGO.

Just checking in to confirm that renaming the schema definition files (according to their respective schema IDs) was indeed sufficient to get this change through review. Thanks, everyone, for your help!

1 Like