© 1999 Boudewijn Rempt
Database Objects, or dbObj for short, is a dynamic object-oriented, repository based layer on top of the Python DB-API II spec.
dbObj is developed in sync with Kura database application. When Kura demands new functionality, I will update dbobj. The current version is 2.1 - there might be bugs, but I haven't found them, and it is pretty full-featured.
Changes since version 2.0: Added a file-based backend. See the textdb module.
Changes since version 1.1: Added unittests. DbObj is now unashamedly MySQL-specific: database-indendence will be restored in the next version. A lot of convenienve functions have been added to the dbAppDef object. Started with cleaning up the code.
Changes since version 1.0: Implemented the dbError exception object, added a createDefaultObject to dbAppDef together with further support for records filled with default fields. SQL DDL generation now really works, added a few features to the repository.
DbObj wraps the DB-API II spec in several layers. At the bottom, there's a wrapper around the interface. the db.py module connects to the database. asks the database to execute queries and returns results. Nota bene: db.dbObj has been renamed to db.dbConn. But you almost never need to access that class, so that shouldn't hurt a bit.
At the next layer, sql.py wraps db.py. sql.py dynamically generates SQL statements for select, update, delete and insert. sql.py uses the data entered in the repository to automatically create joins between a base table and the associated lookup tables.
Above sql.py, the dbobj.py module provides three classes: dbError, dbRecord and dbTable. dbError is to provide a flexible error handling mechanism, but is not usable at present. dbRecord is an abstract record object that knows how to update, delete or insert itself. It can present columns/values in a dictionary and check for referential integrity. The dbTable class represents the outcome of a query. The select function performs a query on the database, based on the fields present in a dbRecord object, and stores the result in a list of dbRecord objects.
Application specific classes
While the classes present in dbobj.py present a generic represention of database objects, the dbObj framework can also work with classes that are specific to the tables represented. For instance, the lng_language table can be represented by a lng_lngg module that contains the lng_language (dbRecord) and lng_languages(dbTable) classes, which might offer extra functionality, like an html presentation builder or complex business rules. These classes can be stored in a dictionary object:
The final layer is the repository. The repository describes the datamodel, enabling the other layers to dynamically approach the data in the database. The appobj.py module offers classes like dbPair, which links a pair of fields (for instance the foreign key field in the base table and the primary key field in the lookup table, dbRelation, which defines the relationship between tables, dbFieldDef, which defines the properties of fields, dbTableDef which stores the properties of tables, and finally dbAppdef, which contains the entire structure. Repositories can be saved to and restored from XML files.
The appObj class stores all application classes in a dictionary, enabling a very generic style of developing.
The repository must be built in application memory upon startup: this can happen either in code (for instance, by building a Python dictionary of objects), or by reading the repository from a file or a database. Currently, reading the repository from an XML definition file is supported.