Each different data source type is handled by a specialized server, called a provider. Every provider access one form of data. This may be a database, but this not necessarily so. It is theoretically possible to access LDAP servers, mailspools and other data sources, as soon as a provider is implemented. Therefore the client library doesn't assume very much about the characteristics of a provider. Therefore the interpretation of the meaning of the name of a source is also left to the provider. To have a unique and easy configurable naming system a configuration file is used. In this file names are mapped to providers and the connection string the provider needs to find the correct data source. How the provider interprets the connection string is described in the section about the specific providers.
GDA providers are CORBA servers which are activated using GOAD. GOAD gets it's configuration information from a set of files which are located in the ${prefix}/etc/CORBA/servers directory, where ${prefix} is the gnome installation path, or from the ~/.gnome/CORBA/servers directory. These files usually have the filename prefix .gnorba. The user directory entries are prefered over the system wide directory. The name of the configuration file is not significant, but the gnome-db packages used gnome_db.gnorba as the filename of the standard configuration file.
Each provider is defined with one section in this file. The current default file shipped with gnome-db contains an example entry for each of the available providers.
(1) [gda-odbc] (2) type=exe (3) repo_id=IDL:GDA/ConnectionFactory:1.0 (4) description=Gnome Datasource Access for ODBC (5) location_info=gda-odbc-srv [gda-mysql] type=exe repo_id=IDL:GDA/ConnectionFactory:1.0 description=Gnome Datasource Access for MySQL location_info=gda-mysql-srv [gda-postgres] type=exe repo_id=IDL:GDA/ConnectionFactory:1.0 description=Gnome Datasource Access for Postgres location_info=gda-postgres-srv [gda-oracle] type=exe repo_id=IDL:GDA/ConnectionFactory:1.0 description=Gnome Datasource Access for Oracle location_info=gda-oracle-srv |
41GOAD Configuration File Entries
Executable providers offer some advantages. They may be hosted on a different machine [1] and the startuptime of the provider is only needed once. The drawback is that if such a provider crashes all the clients are disconnected from the database. To overcome this problem it is possible for each client to request a new copy of the provider (although the client API doesn't yet provide this flag).
The other type of providers are shared library providers. These providers are linked to the client when the client requests something from the provider. The disadvantage is that the server is hosted on the same machine as the client. But a server crash only affects one client. The startup cost is comparable to an executable provider. The big advantage of this sort of providers is that debugging the provider code is simpler, since you must not attach gda to a running provider and you also can catch errors during server initialization.
Per default every GDA provider is available as an executable and as a shared library. The build process and the conventions used to implement the provider make sure that the executable and the shared library are made and installed. Thus, GDA providers are implemented in shared libraries, which are then linked with a small program which just acts as a driver for the shared library.
One of the problem GDA solves is the naming of data sources. Every database system has it's own way of defining names for it's databases. For example MySQL uses the hostname, port number, and the name of the database. Other databases, like Solid use the hostname and port number only. There is no support for multiple databases per server. Because the client does not need all these details, there is a configuration file named gdalib which names the available data sources and defines all the properties of such a data source, so that the correct data base server can be contacted. The information in this configuration file is accessed by the client library and sent to the provider.
The format of the gdalib file follows the Gnome conventions and describes each datasouce and which provider is able to be used as a server.
Here is a part from a gdalib file.
(1) [Datasources] Solid=Solid-entry Postgres-Native=Postgres-Native MySQL-Native=MySQL-Native (2) (3) [Solid-entry] (4) Provider=gda-odbc (5) DSN=Solid (6) Description=Solid Test Database for ODBC Configurator=MODULE=odbc;ENTRY=Solid [Postgres-Native] Provider=gda-postgres DSN=DATABASE=test;HOST=localhost Description=Postgres Test Database in native mode Configurator=None [Postgres-Native] Provider=gda-mysql DSN=DATABASE=test;HOST=localhost;PORT=1111 Description=MySQL Test Database in native mode Configurator=None |
42gdalib File Entries
This functionality is currently not implemented. Therefore the configuration tools for the datasource or a text editor has to be used to do the provider specific configuration.
GDA comes with a configuration GUI to perform database administration tasks. This tool is the gda-mgr application.
As stated before, each provider comes with a configuration module, in the form of a glib module, which is then loaded by the gda-mgr application.
[1] | I don't know yet how to do this. I think the GIOP_FORWARD messages are used in such a situation. I have not yet found out how to do this. I'll do this later |