Keeping database synchronized with STABLE sourcesΒΆ

It can occur that someone wants to change the definition of a persistent class. Unlike introducing new persistent classes, changing a persistent class requires intervention by the central database administrator. The reason is that users may still be using the persistent class as it was before the change. The problem is that the class definition in Python and in the database have to match each other. This means that whenever the Python class is changed the database has to be changed accordingly. Because the database is used by multiple users, all of these users have to adopt the new Python class definition in unison with the database definition. The process to handle this problem requires human intervention at certain stages and is completely described in this section.

  • An improved persistent class has been tested in a separate schema and has been committed. After a while these changes are considered to be the STABLE version.

  • When a change to a persistent class is considered STABLE, the main database administrator has to be contacted. The information that needs to be given is the revision number of the source file that are involved.

  • The main database administrator contacts the administrators of all other databases in the federation that a database type evolution is bound to happen.

  • The main database administrator waits until all administrators of the databases in the federation have responded and agreed a time when they can update the database schema. Alternatively, they can respond that they disable automatic updates of the CVS sources.

  • The main database administrator checks out all (STABLE) sources except for those that are meant to change. In the case of the sources that are to be changed, the revisions that have been given earlier are checked out. This will provide the database administrator with an environment that will be exactly like the next STABLE environment that is being created. The PYTHONPATH has to be set to this checked out version.

  • With a Python environment that represents the upcoming STABLE environment the main database administrator evolves the database schema. The goal is to make sure that the Python and database environment match. All type evolution statements and all other issues that come up are gathered by the main database administrator during the process. The collection of SQL statements and things to watch out for is then sent to the local database administrators.

  • The local database administrators now have to set up an environment in the same way as explained for the main database administrators. In this environment the local database administrators can evolve their local schema. They can use the SQL statements and remarks as sent to them by the main database administrator.

  • Once a local database administrator has succesfully evolved the schema, a confirmation needs to be sent to the main database administrator. Only when all confirmations have arrived the STABLE version can be updated.

  • The main database administrator attaches the STABLE tag in CVSto the revisions as they were supplied. This should only be done if all local database administrators have reported successful schema evolution. The command to be used is:

    cvs tag -r revision_number source_file