GNU The GNADE Project


Editor Michael Erdmann
last update 3. Jan.  2008

Contents

Project Objectives and Organization


The GNADE (GNat Ada Database Environment) project is an open source project with the primary goal to provide all tools and packages necessary to create an Ada 95 development environment providing a seamless integration of relational databases and other database products with Ada 95.

The project provides the following software packages:

The ODBC interface has been selected as primary interface to the underlying data base because most of the known DBCS do provide this interface and it is already well understood and established standard.

The embedded SQL approach has been implemented by several vendors (Informix, Adabas, Oracle eg. PRO*Ada and many more) for Ada and other languages. This aproach allows the reuse of old legacy code.Embedding of SQL in Ada 95 requires either a compiler capable of parsing embedded SQL and Ada at the same time, or (the approach of the GNADE project) a precompiler which expands the SQL code into Ada statements which will be compiled later by the Ada Compiler.

Embedding of SQL in Ada 95 requires either a compiler capable of parsing embedded SQL and Ada at the same time, or (the approach of the GNADE project) a precompiler which expands the SQL code into Ada statements which will be compiled later by the Ada Compiler.

Currently all development is done for the GNU Ada Toolchain (GNAT) but the the support of other compliers is not outside of the project scope. The supported compilers depend on the available maintainers.

The project activities and results are hosted at http://sourceforge.net/projects/gnade.

All technical communication besides of error reporting is done via the mailing list gnade-develop@lists.sourceforge.net

Error reporting should be done by means of the bug reporting facilities at source forge where the project is hosted.

If you like to contribute to the project, please contact Michael Erdmann.

Current Status

The GNADE project provides a complete solution for developing database based applications in Ada 95.This solution allows to use all ODBC complient data base systems.

The components of the GNADE Project, their status and authors are listed in the table below.

Component Author Description Status
Thin ODBC Binding J. Pfeifer Thin ODBC binding which provides all feature of the ODBC interface. Complete
ESQL Translator M.Erdmann This ESQL to Ada translator is based upon the ISO/92 specification with extensions lend from Pro*Ada. The implementation generates code for the thin ODBC binding of Mr. Pfeifer. Complete
Postgres Binding J. Pfeifer
F. Weimer
This is a binding to Postgres which is intended to provide access to the non ODBC features of the Postgres data base. Complete
MySQL Binding Denis Chalon Binding to MySQL which is intended to provide access to the non ODBC features of the MySQL data base. Complete
SQLLite Bindings Ching Bon Lam Binding to SQLite and SQLite3 Open
Oracle OCI Dmitriy Anisimkov This package is currently a stand alone package in the GNADE project. Complete
ADBC Interface Julio Cuano
M.Erdmann
Currently it is a simple trial implementation missing a lot of functionality but i gives a good idea where the development is going to. Currently the interface is available for PostgreSQL and MySQL.
The future of this interface is unclear since there is allmost no response from the community.
Obsolete
Windows S. Leake Since Version 1.3.4 Stephen Leake has taken over the part of the maintenace for windows. Installable packages are currently not available. The current build environment for windows is based on native windows but unfortunatly it is not maintained well. Complete
Object Persistency M. Erdmann In this section we provide one implementation which can only be used for small applications (ODB) and in the contrib section an example how object persistency can be realized on an relational databse. Complete

Implementation Overview

The result of the GNADE project are packaged in different packages as listed below:

Base Package Description Packaging
gnade This package provides all the sources for:
  • ODBC Binding
  • Embedded SQL Translator
  • Native bindings
The following packages are available:

gnade-source - source code

gnade-bin-linux - Linux binaries (rpm)

gnade-bin-win32 - Windows 32 installer

odb This package contains the framework for object persistency. The following packages are available:

odb-src - source code

odb-bin-linux - binaries for linux (rpm)

gsql This package provides an sql query client which works via ODBC.

Embedded SQL for Ada 95

The ISO/92 standard for embedded SQL defines for languages as Cobol, C and Ada how the embed SQL commands into the source code. For each language a certain escape keyword is defined which indicates the begin of an SQL statement. Following such a keyword, the SQL statement is inserted. The SQL syntax is basically the same except for the constructs to implement the communication between application and embedded SQL code.

The application communicates with the underlying data base by means of the following mechanisms:

A typical Ada 95 code fragment containing embedded SQL is shown below:


Delare_ERROR : exception;
Open_ERROR   : exception;

EXEC SQL DECLARE BEGIN                                  (1)
   empno : SQL_Standard.INTEGER;
   ...
EXEC SQL END-EXEC

EXEC SQL                                                (2)
   WHENEVER SQLERROR raise Declare_Error;        

EXEC SQL                                                (3)
   DECLARE emp_cursor CURSOR FOR 
   SELECT empno, name INTO :empno, :name 
FROM employees
WHERE manager = :to_find;

EXEC SQL
WHENEVER SQLERROR raise Open_ERROR;
EXEC SQL (4)
OPEN emp_cursor;

loop
EXEC SQL
FETCH emp_cursor; (5)

exit when SQLCODE in SQL_STANDARD.SQL_ERROR; (6)

Put_Line(.... name );

end loop;

In the example above each statement which is not preceded by the string "EXEC SQL" is assumed to be an Ada 95 statement. Every thing preceded by the EXEC ESQL string till the next semicolon is assumed to be a ISO/92 SQL statement.

Statement 1 : This section contains the declaration of the host variables which are used to communicate between application and dbcs. Important to note, that only a view standard types have been defined in the ISO/92 standard for this purpose.

Statement 2 : This embedded statement declares, that an exception SQL_Error has to be raised when the following query returns the SQLERROR condition. Please note, that this clause is only valid until the next embedded SQL statement is executed (in this case Statement 3).

Statement 3 : This statement defines a cursor denoted by "emp_cursor", it does not create any result set.

Statement 4 : This statement initiates the execution of the query by the underlying data base system and some of the tuples will be made available after that statement returns. However, note that the database engine might block at some point generating these tuples. The engine will unblock, once some of the tuples are fetched in by statement 5.

Statement 5 : This statement fetches a new tuple of the result set of the cursor denoted by "emp_cursor". Important to note that the result of this operation is stored in the host variables as they are defined in the INTO clause of the statement (3).

Statement 6 : The result code SQLCODE is checked. If the SQLCODE indicates, that no record has been found, exit the loop.

The ODBC Interface (by J.Pfeifer)

The ODBC interface consists of a so called driver manager and the ODBC driver it self. The driver manager (DM) is a library that on one site offers the specified ODBC API to applications. The DM therefore is what you essentially link to your application. But in large parts the DM routines are only stubs.
At run time the DM decides which database to access and based on the type of the database which vendors database ODBC driver to load. So basically most DM implementations require that the OS supports dynamic linking and that the database vendors provide the database site of the ODBC drivers as dynamic loadable entity (aka DLL or shared libraries). But the DM does more than just to provide these stubs and the dynamic linking of the corresponding implementations. As ODBC evolves over time, the DM is also responsible to handle the situation that with a new version of ODBC new API entries are defined, but they are not available in a database driver because this driver was developed when an earlier version of ODBC was the rule (for example we now have ODBC 3.52 and the MySQL ODBC driver is written for ODBC 2.5x). So an application might link against an ODBC 3.52 DM and use all the new and hot ODBC entries, although the database used doesn't have them in its ODBC driver. The DM usually reacts in one of two ways:

The mechanism how to select the right driver is system dependent, but the principal idea is that you have some kind of repository where you associate logical names with configuration information telling the DM the specifics which driver to load. On Win32 this repository can be the registry or so called DSN-files, on UNIX this is mostly an ODBC.INI file containing the information in some structured fashion. The application opens the database by specifying such a logical name and its the task of the DM to consult the repository and to dynamically load the right database driver. In this way, a carefully written application can not only be written in a database independent fashion (using the ODBC API), but also the resulting binary can be dynamically configured to use different databases. This is what makes ODBC so successful on Win32 and will make it more and more important also on UNICes. You can write very generic data aware code ranging from applications like MS Access that can operate on any database that supports ODBC, to GUI widgets like data grids that you can incorporate into your GUI application and that binds "magically" to nearly any database you want.

The database ODBC driver is typically a sharable object that implements the ODBC interface on the database site and is loaded by the DM. In theory - although quite uncommon - you may link such a driver directly to your application. This will work if your application makes only ODBC calls that are implemented by the ODBC version used when writing the database driver. Your application then is written in a database independent fashion, but the binary is bound to a specific database.

Native Bindings

The ODBC provides a standardized way to access a data base which is completely sufficient to implement applications. Any how every DBCS provides services and features which are not supported ODBC, but exactly these additional features may be the the reason why a certain DBCS is selected for usage. For this reason does the GNADE project provide so called native bindings to several DBCS client libraries.
The purpose of these libraries is to provide a interface to the vendor specific features of a data base system. This topic is a low priority issue in Version 1.0. This will change with Version 3.0. This Version will attempt to provide an interface which will allow the use embedded SQL and the native bindings in the same Ada 95 source package.

Currently available are the following bindings:

Object Persistency

Object persistency for Ada 95 is introduced by means of a small language extension. A Ada 95 data type can be declared as persistent using the following construct:

   type Object is persistent record
First_Name : attribute String( 1..40 ) := (others =>' ');
Last_Name : attribute String( 1..40 ) := (others =>' ');
Boss : attribute Persistent.Reference := null;
end record ;

Object persistency means, that the object survives the shutdown of the application. In order to achive this, the object has to be wirtten into some kind of persistent storage, from where it is retrieved upon start of the appliation. This requieres, that every object has some kind of unique object identifier. In the current implementation it is a task of the application to define the object identifier.

with MyObject;
with ODB.Persistent;
with ODB.Storage.File;
......
use ODB;
procedure Main is
O : ODB.Reference ;
File_Store : File.Object; (1)
begin
File.Load(File_Store); (2)

O := Lookup_Object( "First_Object" ); (3)
if O = null then
O := new Person.Object; (4)
Object_Name( O, "First_Object" );

O.A := 1;
end if;
........... do some thing ......

File.Save(File_Store); (5)
exception
when Others =>
,.......
end Main;

In (1) a file object is decalred which is used to access the persistent storage which is in fact loaded in (2). At this point only the object directory is loaded but not the objects them self.

In (3) a lookup for the given object identifier is done. If the lookup return null, the object is not yet existing and it will be created by means of (4) and a name is assigned to the object.

At termination of the application the currently loaded objects are wirtten back into the persistent storage.

The currently implementation provides only user local binary and xml files. A server based aproach is under construction.

For more information please refere to the documentation of ODB.

The directory gnade/contrib/objects contains a technology demonstration which shows how to use an object oriented approach  together with a RDBMS. This is a protoying effort and currently under development. For more details either refere to the CVS and the documentation.

Development Agenda

The table below list the current development Agenda:


Project Description Status
ODB Object Persistency for Ada 95

This topic is dedicated to the idea, to provide object persistency with Ada 95 with an underlying RDBS.

The current implementation is called ODB and is abvailable as source package only for the IA686/Linux architectur from the summary page of the GNADE project.

The ODB implementation is based on the fact, that all persistent objects are derived from a base class called ODB.Persistent. All objects derived from this class are allocated in the same storage pool. This storage pool can be written on a persistent storage media, from where it can be read in to restore the state of the pool. Each object in the psersistent pool has to be named in order to be persistent.

The current implementation provides only an interface to store objects in a local files systems. The next step in the development is to provide a server which provides means of  storing objects central on an dedicated server.

For the documentation of this package the first time UML has been used by using the ArgoUML tool.

Released.
GSQL SQL IDE based on GtkAda and ODBC

Currently Michael Erdmann is developing an IDE on Linux which allows to develope SQL based projects. The IDE has the following features:

  • The project file contains all defintions as queries, procedures and table definitions
  • The IDE contains different support editors for queries, procedures and tables.

Export functions

Release but outdated. Some body need to Adopt to the latest GtkAda Version.
ADBC (ADBC) - Ada Database Connectivity Interface

After the release of the Version 1.1.3 a discussion about the further development directions of the GNADE project has been initiated. After a short discussion it became apperant that a simple programing model for data base access is needed. A simple API has to hide the native bindings, the ODBC interface and other interfaces behind one generic API as shown below:

The working title of this initiative is Ada Database Connectivity (ADBC) which will change in the future. A white paper describes the current vision of this interface has been put to review in the GNADE and comp.lang.ada community. Any contribution to this issue (either review, new requirements or implementation) is highly wellcome.

The current distribution of the GNADE project contains an experimental implementation of this interface. Since this interface is fairly unstable it should not used for any development right now.

Developement Stoped, but comments are wellcome.

Command line tool set

Since the ODBC interface provides a portable way to access data bases, the project provides a basic set of command line tools which should work on top of every data base. These tools are continusly developed based.

This is a part of the GNADE release. Until no new requirements are specified nothing will change..




Object Oriented Databases

All the previously presented approaches don't take the object oriented features of Ada 95 into account. In the context of this no activity has been planed yet, but an interesting point would be to achieve some kind of object persistence for Ada 95. For further information on this issue you may refere to http://www.cetus-links.org/.

The package ODB provides a small language extension to Ada 95 which provides small scale object persistency.

Supported Platforms and Databases

This section summaries the major software platform and databases known to support the GNADE project.

Component Version Origin
Operating System Linux
Solaris
Windows NT
Windows 2000
SuSe, Redhat, Debian
SUN
Microsoft
Database PostgreSQL Server 7.0.3
MySQL 3.23
MimerSQL 8.2
Oracle 8i
www.postgresql.org
www.mysql.com
www.mimer.com
www.oracle.com
Ada 95 Compiler GNU Ada Tool chain 3.13p Ada Linux Team
ODBC Driver unixODBC 1.8.12-2 Redhat distribution or www.unixodbc.org
for SuSe http://www.familiepfeifer.de/software/RPMs.html

If you find any additional environment or you have ported the software to a new environment please keep us informed that we can update this list and include your modification into the next major release..

Release Road map

GNADE 1.4.2 -End of February 2003

The basic functionality of the GNADE package is assumed to be stable, which mean no further major developments are planed for this release. This release features the first time the command line tool set for the ODBC interface.

GNADE 1.4.3 - End of May 2003

This release provides only bug fixes.

GNADE 1.5.0 - End of August 2003

SQLite and bug fixes

GNADE 1.6.0 - Dec. 2006

Common Build for Windows & Linux and other Platforms; Ada 2005 compatible.

GNADE  2.0 - End of November. 2007

The following features are planed:
- All outstanding error corrections
- GPS projectfile compatibility

Currently the build process is in the process of beeing revised in order simplify the process of building on Windows and Linux OS's.


Project Communication

The project internal communication is done via two channels:

The technical discussion is done via a public mailing list which is hosted at sourceforge:

gnade-develop@lists.sourceforge.net

To subscribe or handle your preferences send a message with Help as contents to:

gnade-develop-request@lists.sourceforge.net

or use the web based interface.

The release of new software is automatically announced by the sourceforge site if you register your self to monitor a certain software package on the sourceforge project page (http://sourceforge.net/projects/gnade).

License and Download


The code of the GNADE project has been placed under the GNU Public License (GPL) with the following extension::

As a special exception, if other files instantiate generics from GNADE Ada units, or you link GNADE Ada units or libraries with other files to produce an executable, these units or libraries do not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU Public License.

The following explaination published at comp.lang.ada may help you to understand the consequences of this so called "GNAT Modified GPL":

If you use GPL software in your software, your software is forced to itself abide by the GPL and its source must be released, i.e., the GPL software "infects" yours. The LGPL normally typically applies to libraries, such as shared libraries or DLLs. Linking to an LGPL licensed library _does_not_ cause your software to become GPLed. (The definition of "linking" in this context was a focus of the recent cla GPL thread.) The "GNAT Modified GPL (GMGPL)", a portion of which is quoted above, allows GMGPL-covered software (such as the bodies of generics) to be included in your software without "infecting" your software with the GPL. The GMGPL covered software itself remains free, and any changes made to that software must be free, but that aspect of that license ends at the unit's boundary. Your software can be free, open source, or proprietary, the GMGPL does not influence that aspect, though the use of other software yours employs might (e.g. using GPL software).

There are three methods of getting GNADE:

 

        Usage of Labels and braches

The development will continue on the main line and the changes done in the production branch are merged regualry in the main line (trunk) if applicable.

Resources

There are some documents about and arround the GNADE project available:


Description of the GNADE project for the Ada 2002 Conference gnade.pdf or gnade.ps
Presentation at ACT meeting july 2002 act-26-06-2002.tar.gz

Projects known to use GNADE

I expect that this list is not complete, since i dont ask for feedback explicitly but at least sometimes i get some information about project applicaitons. These are listed below.

Other Ada RDBMS interface projects

Below you find a list Ada 95 projects providing Database interfaces to RDBMS products.


 

© 2001-2008 Michael Erdmann

$Revision: 1.34 $ $Date: 2008/01/03 08:23:47 $