Tsine uses database for storing and accessing configuration data during timetable computation. This allows multiple calculations to be performed at the same time. It also guaranties data consistency.
For the first implementation, PostgreSQL is used, for its transaction capabilities and good SQL support (better than MySQL). However, the API could be easily transferred to a different database system with simmilar capabilities.
In order to load data to the database, a script called tsineDbLoader.py has to be called. It accepts folowing arguments:
-h/--host – hostname for your DB server (default: localhost)
-u/--user – DB username (default: luigi)
-p/--passwd – DB password (default: none)
-d/--db – database name (default: tsine)
-s/--dsn – DSN name (default: localhost)
--table-prefix – prefix used for tables (default: none)
--data – configuration data file in format according to specification (default: school.xml)
This scripts deletes old tables (if there are any) and creates new tables (executes SQL commands in sql/tables.sql) and fills them with data from data file (see above - --data option)
Following tables are used to represent the configuration in database (use –table-prefix option to adjust their real names) – for the meaning of certain terms, see configuration file documentation.
roomcategory – stores a list of available room categories
building – list of available buildings
buildingdistance – relation of distance between two buildings (in minutes of travel)
room – list of rooms, with reference to building the specified room is in
teacher – information about teachers
subject – information about subjects taught
students – information about student groups, with (optional) reference to the layout they are contained in
studentsLayout – list of students layouts available, with reference to the group the layout belongs in
timetableitem – list of items to be scheduled into the timetable
roomcategories – relation between room and room category
timepref – teacher's time preference
roompref – teacher's room preference
Note that due to different constraints between the tables, the order of table creation is very important. It also means, that data loading may not work properly, if different section of configuration XML file are swapped (however, the XML Schema description should validate this constraint).
The script is written in Python, and uses portable DB-API for communication with PostgreSQL (module pgdb) and standart Python XML API, xml.sax module. It simply connects to the database, and while reading the XML input, executes reguired queries, and commits whole transaction if everything was OK, otherwise, it rollbacks it (ie. in case of bad input format etc.).
At the beginning, all tables (that are to be modified) and data are erased, and new ones are created again. Because of this, no previous initialization of the DB is needed. If user wants to preserve old tables in the DB (ie. for a different timetable computation), they have to use –table-prefix option. This shall not harm performance very much, because the data are loaded just once before running the computation.
The main part of the script is the DBLoader class, which implement the xml.sax.handler.ContentHandler interface to provide element handling functions. It consists of several function, usually with the same semantics – read an element attributes, and create an INSERT query.