rdbGUI/rdbModel new stuff

Goal is to provide better support for certain common operations. "Better support" means they should be as simple as possible to invoke interactively and that various constraints on the data in the database should be respected. The latter point has at least two implications for the implementation:

Every time a row is inserted or updated it should be checked for internal consistency and legality
All fields identified as to be filled in by the service (e.g., user id of creator, update-time timestamp) should in fact be filled in by the service.
When a new row is inserted or an old one is updated, it may be necessary to update other existing rows.

This philosophy is to be implemented completely—or as completely as can be managed—for certain common operations, and at least partially (1. and 2. above) for all inserts and updates.

Architecture

All information about the structure of the (calibration metadata) database (hereinafter just called "the database". In fact everything in rdbGUI and rdbModel is completely general with no special knowledge of the calibration metadata database) and constraints on its contents is kept in an xml file, constructed according to the schema in rdbModel/xml/rdbmsDescrip.xsd. The description of the structure of the database has been there since Day 1 of rdbGUI. What's new is the use of assertions to describe constraints and how they should be evaluated when an insert or update of a particular kind is done.

The xml file is parsed by rdbModel; the information in it is made available via the public interfaces of classes describing columns, assertions, etc. This also has always been true, however some classes have been added for new parts in the xml description.

rdbModel has classes dedicated to handling the connection to the actual database (e.g., MysqlConnection which is a concrete implementation of the pure virtual class Connection) and others (Rdb, Table, Column and so forth) for keeping track of the information in the xml file. The connection classes have functions to do standard database operations query, insert and update, but these are "dumb" in the sense that they are just wrappers for SQL commands; they don't know anything about the particular database and so can't enforce any validity checking. The new stuff adds insert and update functions to Rdb which have access to constraint information. They should handle 1. and 2. above. Additional special-purpose functions have also been added for more specific operations which may have application-dependent aspects: insertLatest and supersede.

Finally, rdbGUI needs to make use of the new functions and also of some of the new information in the xml description in order to be able to present the right set of options to the user

Status

The new schema, describing how to specify new information needed for this venture, is done (insofar as anything is ever done; that is, until it's found lacking). It includes, among other new elements, one called <insertNew> (Joanne should probably change it to <insertLatest>, to be consistent with name in code) and another called <supersede>, describing constraints for two special cases of inserting a new row.
A particular xml file using this schema to describe our calibration metatdata dbs is also done, except it's already clear that it will need some small changes or additions.
The smarter rdbModel insert and update functions are done and checked out.
An insertLatest function in rdbModel has been written and checked out. It uses the information in the <insertNew> element to handle the case of inserting a new calibration which is the latest (that is, has latest vstart) of its type.
A supersedeRow function in rdbModel has been written and checked out. It uses the information in the <supersede> element.
rdbGUI (latest tag) has been modified to use the new Rdb somewhat-smart insert and update functions.
Need to add menu items and work out other user interface issues for rdbGUI to make use of the higher-level insertLatest and supersede functions (see next section).

Implementation sketch for TO-DO items

insertLatest

Access should be from Action menu, same as for regular insert. The distinctive feature of it is the situation it's appropriate for: inserting a new calibration whose validity start and end times are later than any existing comparable (same flavor, same instrument, etc.) type.

Could be that the usual insert dialog would fit insert latest as well. Then the only difference for rdbGUI would be to call rdbModel::Rdb::insertLatest rather than rdbModel::Rdb::insertRow once the user's input has been accepted. The other difference is that there are more outcomes for insert latest, but this wouldn't affect rdbGUI much.

supersede

This function would be accessed via the ResultTable pop-up since the idea is that the user wants to supersede a particular pre-exisiting calibration. Some fields in the new row must be the same as the ones in the row to be superseded, or must be assigned a fixed value. These should not be presented to the user at all. Others should be presented with default = value in old row, and still others should be presented with blank value (must be filled in by user). rdbGUI can get lists of the column names for the last two kinds from the rdbModel::Supersede functions getOldDefaulted() and getAsk()

Interface for rdb::supersedeRow is

 Rdb::supersedeRow(const std::string& tablename, Row& row, int oldKey, int* auto_value=0)

This is not so different from Rdb::insertRow and Rdb::insertLatest, which is not surprising since it's just a special case of insertRow. The differences are that the Row object argument will tend to specify fewer columns and there is an extra argument oldKey which refers to the row to be superseded.

Last updated 20 July 2005
Source for this file may be found on Joanne's laptop in doc directory of rdbModel.