GNOME Bugzilla – Bug 136736
Database version read/set and a migration utility required.
Last modified: 2005-02-18 09:13:04 UTC
When you save plans to a database then the following is naturally required to help maintain the quality of the databases, a) A versioning field of some kind so that Planner can detect the exact schema version of a database, b) A migration script or utility so that people can upgrade a database easily. Ideally this should be in aspirational version 1.0 release candidate of planner so that the peocedures are defined from version 1.0 onwards. For XML files planner has the ability of detecting the correct XML DTD to use but this isn't done for the database storage. It is a very essential feature if people start to rely on Planner in anger. Its been suggested by Richard to also look at the zenity (a GNOME GUI tool) and I agree that would be nice way of doing it. So we document the commands done so that anyone else can create their own custom scripts, but provide a Zenity script for all other users. Actually upgrading a database is easy as long as the set of upgrade SQL statements is created by the developer. Whoever does any patches that changes the schema must provide the upgrade procedure the last schema version (they have to do the DTD also). It follows that an upgrade from any previous schema is simply the execution of each upgrade SQL file in turn, layering the upgrade SQL commands on top of each other in a loop until any previous version of a database is now up to the most recent version i.e., Prev-2 -> Prev-1 -> Prev -> New. Rgds, Lincoln.
Also need projects inside database to be administered, - create database, - delete database, - upgrade database (schema), - delete project, - lock project (with clear lock), - set project permissions (maybe), Actually - don't like zenity in the end - probably use Planner itself to create/upgrade databases.
Yeah, probably a good idea to write a tool. It could be put in the sql plugin.
Also need to clean up what happens when you try and exit with an unsaved unnamed project - you get ... (planner:15585): Gtk-WARNING **: Failed to set label from markup due to error parsing markup: Error on line 1: Character '=' is not valid inside an entity name ....because the URI is sort of complex and isn't safe to display as a entity name (bonobo) as it stands as a string. I looked at the code and there is no obvious fix so really need to force a database name to be strdup'd to "Unnamed" as opposed to being left NULL.
Here is an example of what I was thinking of on the database migration GUI.... Its cluttered as it has all three things, Manage Database (where you create new/delete/upgrade databases) Manage Projects (where you migrate a project from one schema to a new one or delete projects. Also this is what I was thinking of on the locking and permissions) On the permissions, If you have access to the database for one project then you have access for all projects. I want to add a new layer of authentication so that web front ends get per-project permissions and the you keep the postgresql database password secret (only known to the CGI/php script). We should probably split thi sout into separate bugzillas.
Created attachment 29036 [details] Screen grab showing ideas on the database.
I'm going to close this as we have upgrading in planner now. Please don't add 10 different bugs to each report, it makes bugzilla impossible to keep clean. If any of the other ideas here make sense, feel free to open new bugs for those.