State of the DA


	Goals

		In order for Zope v2 to be a success, the already substantial integration 
		between the object-oriented world of Zope and the relational world of 
		the RDBMS must be maintained, and even enhanced.  Toward this goal, this 
		document outlines three things:

			o Levels of integration with Zope2 for Database Adapters (DAs).

			o Current status of all existing DAs, with swags at difficulting in 
		  	increasing the level of integration.

			o A quick hack to fix DAs to be "functional".

	Levels of Integration

		The first effort is directed toward quanifying the different levels of 
		integration with the Zope infrastructure, and are foccused largely on 
		concurrency integration.  There are several issues that are needed to 
		define the different levels:

			o Thread safety

			o Concurrency to seperate databases

			o Concurrency to a single database

		By isolating each of these issues, we can determine areas to focus on for 
		improvement.


		Level One (L1)

			At this level, the only requirement is that it has to be functional with 
			Zope2 running in single threaded configuraton.  This is the level that 
			all DAs will start out when they are written, most likely.  The results 
			of running the DA in multi-threaded mode are undefined.

			DAs which do not support any form of thread-safety should implement a 
			safety mechanism to prevent it from being used in a mutli-threaded 
			fashion.


		Level Two (L2)

			For Level Two DAs, the only requirement is that the DA be callable from 
			multiple threads.  What this means in practice is that the DA should 
			behave properly when multiple copies of of a Database Connection object 
			are instantiated in multiple threads.  Most implementations of this 
			level will use a global lock to prevent multiple accesses to the 
			underlying API at the same time.


		Level Three (L3)

			At Level Three, the DA is required to implement and fully support 
			multi-threaded behaviour.  This means that it must support mutliple 
			copies of the same Database Connection in multiple threads with full 
			access concurrency.  In addition, the DA must release the Python global 
			interpreter lock while waiting on the database server to respond.


	Database Adapter Status

		This section begins to outline the current status of all the DAs that 
		are supported by Digital Creations.  We have not even begun to look at 
		all the DAs that have been written by other people, but will provide 
		guidance to those wishing to bring them in line with the new architecture.


		Oracle (dcoracle)

			Currently, the Oracle DA is not thread-safe, however, because the 
			underlying APIs to Oracle (as of release 7.3 of Oracle7) are 
			thread-safe, it should be possible to fix with minimal effort. Today it 
			is L1 compatible.

			*Proposed Solution.*  Bring the Oracle DA up to Level 3 compliance by 
			modifying the call format to fit what is expected by Oracle for 
			thread-safe behaviour.


		ODBC

			ODBC presents a totally different problem set.  While the ODBC driver 
			itself can be made thread safe, the question of thread safety extends 
			down to the database driver level as well---and not all database 
			drivers are thread safe.  Today it is L1 compatible.

			*Proposed Solution.*  Near term, bring ODBC up to Level 2 compliance for 
			all underlying drivers.  Long term, the DA should adapt to the 
			capabilities of the underlying driver being used, choosing either L2 or 
			L3 behaviour.


		MySQL

			MySQL presents an interesting situation.  In many ways it is a full 
			featured database, but it is missing one critical component: transactions. 
			Currently MySQL is not thread-safe.  It is therefore only L1 compatible.

			*Proposed Solution.*  Because of its lack of transactions, and the 
			difficulty in managing locks otherwise, the MySQL DA will never go over 
			level L2


		Solid

			Unknown. Solid has recently modified their entire corporate strategy, 
			and the future of the Solid DA is uncertain.

			*Proposed Solution.*  Eliminate official support for SOLID given the 
			current murkiness of its future.


		Gadfly

			The Gadfly database, written by Aaron Waters and 100% in Python (with 
			optional C extensions) has been used for a lot of demonstration 
			purposes. Currently it is only functional at Level 1.

			*Proposed Solution.*  Bring Gadfly up to L2, and consider moving to a 
			client/server implementation of it.