Implementation of GDA Providers

The purpose of the gda-server library is to hide all the CORBA details from the provider's programmer and avoid duplication of work which leads to code that is much easier to debug. That library stands at the same level as the gda-client library from the CORBA point of view.

The gda-server library imposes a framework on the way the provider needs to be implemented, but allows for specific customization.

Objects in the library

All the objects here are the mirror objects from the gda-client library from the server side of the libgda CORBA framework. These objects are:

How a query is processed

When a client makes a query, what happens in the server side is:

  1. A GdaServerConnection is created

  2. The connection is opened

  3. A GdaServerCommand is created

  4. The actual command is set in the GdaServerCommand object

  5. The command is executed, and if no error occurs, a GdaServerRecordset is created and returned

  6. The GdaServerCommand can safely be destroyed

  7. The first row of the recordset can be examined, then the 2nd, etc

  8. The GdaServerRecordset is destroyed

  9. The connection can be closed, and the GdaServerConnection can be destroyed.

Actual DBMS customization work

All the steps described above are imposed by the libgda framework. The work of writing a provider for a specific DBMS is in writing the specific parts of the operations described above.

As the C library for a DBMS uses some specific structures to handle connection references, etc, it is possible to attach some information to the gda-server library objects. So usually the provider's programmer defines the following structures (here replace DBMS for the actual DBMS name like for example MYSQL or POSTGRES):