1.4.1 Background

Most database engines currently have many common features but their differences are such that Python code written for one database engine using the DB-API 2.0 is unlikely to work with another database engine without some degree of modification. To complicate matters further many DB-API 2.0 drivers are not actually fully DB-API 2.0 compliant.

Variation between database engines occurs in SQL syntax, choice of field types and choice of which Python object to use to represent field values.

The DB-API 2.0 specification was designed with these differences in mind so that module implementers could make full use of the features of their particular database engine. This module provides a simple, standardised and portable API and SQL dialect which also exposes the interface components of the underlying DB-API 2.0 cursor. In this way users can access a database in a simplified and portable fashion for simple operations whilst exposing the DB-API 2.0 interface for more complex operations.

The drawback of this approach is that some of the fields available in a particular database will not be available through this module. Also there is no support for complex SQL commands including indexes or views since not all databases support them. The approach is only to support what is available to all databases being used.

If a database-specific feature is needed for a specific call you can always use the underlying cursor object directly. By using the web.database module as much as possible you will still make your code more portable across databases should you ever need to change servers and by using the web.database module exclusively you can gain true database portability.

One of the major advantages of using web.database is that it comes with a pure Python SQL engine named SnakeSQL which fully implements the specification (albeit slowly) so if you use web.database in your own code you can guarantee your users will be able to run your application even if they do not have access to a better known database engine.

Comments and questions about this specification may be directed to James Gardner at docs at pythonweb.org.