The purpose of the gda-server library is to hide all the CORBA stuff from the provider's programmer and avoid duplication of work which leads to a code much more easy to debug. That lib stands at the same level as the gda-client lib 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.
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:
the Gda_ServerConnection object: this is the main object and handles everything regarding a connection to the DBMS (given the DB name, user name, password, etc). Usually the client will use only one of this kind of object.
the Gda_ServerCommand object: this object is used to prepare a query to be executed.
the Gda_ServerRecordset object: every time a command is executed, an object of this type is returned, and can then be examined to see what the results of the command were. Under libgda, the recordset is examined in a sequential way, row after row (for some DBMS it is the way query results are handled while for others there is a possible random access).
the Gda_ServerField object: for every column, an object of this kind is used. It describes the column name, the data type, and its contents. Each Gda_ServerField object will be initialized when the recordset is created, and a new value will be stored in it every time a new row is examined. The gda-server will then use these objects to send the contents to the client CORBA side.
When a client makes a query, what happens in the server side is:
1- a Gda_ServerConnection is created
2- the connection is opened
3 - a Gda_ServerCommand is created
4 - the actual command is set in the Gda_ServerCommand object
5- the command is executed, and if no error occurs, a Gda_ServerRecordset is created and returned
6 - the Gda_ServerCommand can safely be destroyed
7- the first row of the recordset can be examined, then the 2nd, etc
8- the Gda_ServerRecordset is destroyed
9- the connection can be closed, and the Gda_ServerConnection can be destroyed.
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):
a connection structure usually named DBMS_Connection
a command structure usually named DBMS_Command
a recordset structure usually named DBMS_Recordset