College Time Table | ©graeme foster |
Home | Work Done | Documentation | User Manual | Source | Screens |
This section describes how the database is accessed from within the time-table application. This project is a database intensive application and uses a multi user database that will reside on a server. The following describes some of the fundamental points that have been considered when designing the application.
Whilst a lot of emphasis is given to data synchronisation it is important to realise that this application is primarily used to view data. That is the majority of the users wish to see the data, to query the data, but not to actually modify it. This is reflected in the approach take in that whilst importance is given to the ideal of seamless synchronisation it is an aspiration to achieve rather than a necessity.
The Qt library supports synchronisation within an application through the use of the MVC pattern and specifically the way it links models to the GUI controls. This is a core approach and is fundamental in the design of the project.
There are a number of open source databases that are available. PostgreSQL was chosen because of it's track record of user functions and views that was decided to be the approach of communication with the applications in a consistent way.
To minimise the database interactions (for the administrative module - the first to be written) it was decided to load all of the necessary data into memory at the start and then ensure that the data is kept in sync. The design of approach generated three primary classes, and are called sql, dbList and dbListManager
This class it intended to be the only interface with the Qt libraries that are used to interact with the database. This class has been designed as a singleton class. This presents a problem when multiple queries are required simultaneously.
For example when the Institute data is loaded this done in a simple loop and for each institute that is returned another query is performed getting all the Faculties that belong to that Institute, additionally other calls are done to get details about the Programmes offered and about the Room facilities. The problem arises when the query is done on the same result set, the result set that contains the list of all Faculty within a given Institute would overwrite the Institute result set. The solution is to set cursors, essentially each result set is pushed onto a stack for preservation and later recover. This is done with the functions setCursor() and restoreCursor()
This class acts as a container for all of the rows of a table. Each row is held in an object which is a subclass of the abstract class called DataClass.
The class provides a number of useful methods.
The access methods are list() and allChildren() which return the entire list or a list of those objects that are a child of a specific object. For example it might be a list of all modules that belong to a specific programme.
The modification methods are used to alter the list, these are insert() append() remove() and resort(). insert and remove require a valid position to be provided, in the case of insert if the posn is invalid then an append will occur, for remove nothing will happen, if remove is successful then the object that was removed is returned. The resort method will sort the list according to the rules of the comparison method that is passed in.
The information methods are size(), at() and dump(), with size returning the size of the list, at returning the object at the requested position and dump displaying some diagnostics for testing purposes.
The class acts as a manager for all the dbLists that are required. It will ensure that the lists reflect the current state on the database as well as notifying all models that are used of any changes to a list. This class is closely coupled to the working of the Qt Model/View.
The class has a nested class registeredModels which holds the data for each model and the lists that model uses and thus wishes to register an interest on any update to the data. It is teh registeredModels functionality along with the Qt Model/View that allows data updates to be reflected across the application.
When a new value is to be inserted onto the database the insert function should be called with the following arguments
The index is another Qt concept and is the way that is used to locate (or refer to) an item within a complex GUI. An example call to Insert is given below
dataLists->insert(item, list, index, item->getItemData()->dcCompareCI);
The insert method will first locate where in the list the new object should be positioned, this is to maintain the sort order. It will then insert the object into the list. Next it will ensure that all the widgets know about this new object by calling updateRMInsert(), this method will step through all the registered models and see which ones have registered the list which this new object belongs to. Finally the insert method will save the data on the database.
When an existing value is updated the update function should be called with the following arguments
An example call to Update is given below
dataLists->update(item, list, item->riCompareCI);
The update method doesn't need to change the data since this is done automatically, however it is possible that the data change will generate a new sort order and so this method will first resort the list using the compare method for the DataClass that is passed in. Then it will notify all registered models via the updateRMUpdate() method. Finally the update method will save the data on the database.
When an existing value is deleted the remove function should be called with the following arguments
An example call to Remove is given below
dataLists->remove(item, list);
The delete method will first locate and then remove the object from the list. Then if a cascade delete is required it will ensure that all child object are also removed by calling the removeAllChildren() method. Then it will notify all registered models via the updateRMDelete() method. Finally the remove method will delete the data from the database.
This approach is intended to isolate all interactions to the database with a clearly identified interface. This interface is then responsible for ensuring that the underlying data is synchronised and that the views know about any changes to the data.
The approach of getting all the data is only for the administrative module and it does lack appropriate scalability however by isolating the logic into a single point it means that modifying this should be much easier than if database access was not so rigorously controlled.
Because all interactiosn with the database shoudl be done through these classes it means that whenever new tables are added then the dbListManager class needs to be expanded to cater for this new data.
This provides a singe point of access to the database
This project is supported by |