Gui reprocessing: take 2

[tmichela]

An alternative to #307

Here we save the context information in the database when we either save it from the GUI or detect it has changed upon processing or context file checking.

Would that be a preferred approache? @JamesWrigley @takluyver
It's still fast to load if the context is saved from the editor, but will execute the context file if it has changed from an other source.
side effect: poor-man's version control for the context file.

[JamesWrigley]

I feel like I'm missing something, don't we already do this with the variables table?

[tmichela]

the variables table contains all variables in the database.
The set of variable in the context file is often a subset of that.

[JamesWrigley]

But that's good enough I think, we can still distinguish context file variables and user-editable variables by checking their type (only user-editable variables have a type, though perhaps we should formalize the distinction).

[tmichela]

It's not just about user editable variables.
Often, there are quite a bit of changes when people are working on the context file and there might be a bunch of old variables that are removed from the context file over time.
In practice it feels a bit cluttered and confusing to list variables that don't exist, especially when there are a lot of it.

[JamesWrigley]

Mmm ok, but those variables will still show up in the table and column settings dialog. I think the proper fix would be to prompt the user to clean up non-existent variables? It's already possible to delete variables from the database and HDF5 files, maybe we could have a Cleanup button in the column settings dialog that will automatically delete the variables not in the context file? That feels like a fairly rare operation so I think we can get away with reloading it from disk.

[takluyver]

I've also been wondering about automatically deleting variables which were previously in the context file but have no data (e.g. you renamed a function without it ever running successfully).