Tracking editable databases using the ab_settings file

[tmillross]

Provides more detail on how to implement the settings file based on the pseudocode in #7 and design plan #8. Relates to this upsream issue.

Context In a meeting with @bsteubing and @AnjeKnottnerus , it was decided that a user should be able to maintain their list of read-only = True/False databases between AB sessions (after close). The default is read-only=True. So only editable databases (read-only=False) must be stored in the settings file. To uniquely identify a database, the BW project that contains it must also be known.

Current state

• File "ab_settings.json" is created the first time a user changes an AB setting. It is saved on the local user machine in the location where the AB is run from, e.g.: _C:\coding_projects\activity-browser\activitybrowser
• Settings can currently only be changed by the user through ABWizard which is accessed via AB GUI > File > Settings.
• activity_browser/app/ui/widgets/settings_wizard.py class SettingsWizard() defines the interface and some behavior.
• activity_browser/app/settings.py class ABSettings() loads and writes the file.

Plan Add the new read-only-related settings without interfering with existing behaviour

• this includes not saving over any pre-existing settings
• and ensuring 'restore defaults' functionality of settings wizard does not change the read-only settings (preliminary research suggests the way settings are loaded and saved will handle these conditions automatically)

Proposed data structure { …other settings e.g. "startup_project": "Meta-analysis"…, "projects": { "Meta-analysis": { "editable-databases": [ "Sandpit3.4","..." ] } } }

Comments

1. The top level key within the settings file: "projects", can contain other settings that related to the projects level of the BW/AB organisational hierarchy.
2. Under this key, the unique project names are used as keys
3. For each project, dbs that can be edited for a particlar project are saved as a list
4. 'editable-databases sounds a bit clunky, open to alternative ideas

[aj-9636]

Suggestions 4.:

• unlocked/locked databases
• databases/read-only databases
• user database
• project database

[haasad]

Suggestion for the management of read-only databases: Instead of putting this information in a single file with complicated hierarchy, you could have a separate file for every project. You could then make use of the fact that brightway already creates a directory hierarchy for all projects and just save it there (eg. /home/adrian/.local/share/Brightway3/default.c21f969b5f03d33d43e04f8f136e7682 for my default project.) This has the added benefit that your read-only settings are copied if you copy the whole project.

In my opinion it is also not necessary to manage editable databases via the settings wizard. I think it would be enough to sync the read-only-column in the databases-table with this file. Like this you can just tick and untick the read-only attribute. Maybe add a confirmation-dialog when changing from read-only to editable.

The file would then also be super simple, cause it's just the json of a dictionary with this format:

{'biosphere3': True,
 'database_1': False,
 'database_2': True}

[tmillross]

Thanks for the suggestion. This is my attempt to identify the advantages of each approach: Choice A: settings file

1. All AB settings stored in one place
2. No file sprawl, including the necessity for the AB to open and read from all project-specific settings files on loading the database table

Choice B: project directory files

1. read-only settings copied if you copy the bw project directory

Regarding the "complicated hierarchy" - I don't see the suggested embedded dictionary structure as cause for concern. Although I accept that the 'multiple files' approach would result in an even simpler structure.

Regarding "...not necessary to manage editable databases via the settings wizard" - we agree! That's the current state rather than part of the plan :)

As an inexperienced user of BW (and AB) - I don't know how important the advantage of choice B is. Is that a common scenario?

Also - when copying a project, does it matter much if all databases return to their read-only default again? If so, then when copied through the AB, we could ensure the read-only settings are also carried over with the copy operation. If copied outside of the AB, the user would need to tick a few boxes again under that scenario.

I'm leaning towards Choice A still at the mo!

[tmillross]

btw I came around to your thinking on this @haasad :)