Why I'm not using libgda

The History

A few years ago I worked as a developer of a billing system and I had to face the challenge choosing the development tool for Linux. So I would like to find a nice and an easy­to­use development tool for DBMS Oracle. I have found a lot of good tools for Windows, but they were very expensive. For Linux I was able to find only one programm ­ Tora. Tora is a nice tool but unfortunately very unstable, that is why I had to refuse it. I have chosen SQL Navigator for Windows because of its functionality.

Apart from Oracle we have used PostgreSQL and I had a dream to have a tool like SQL Navigator but with PostgreSQL support. Unfortunately, there was no such tool. So I have started to think about a creation of a functional tool like SQL Navigator which could operate with different database. I proceeded to development in 2006 in summer.

So the basic questions for me were the next...

• Native DBMS access (not via ODBC layer)
• Databased objects organised into a tree Intuitive and easy database objects handling
• Query (plan builder, constructor)
• Result export/import (in XML, CSV, HTML)
• Debugger (depending on RDBMS)
• Database administration functions and system monitoring
• GNOME integration (via gconf and gnome-keyring)
• Plugins support

The first and the main is a direct access to database. Later I'll explain to you why it's very important. The second is the database objects organised into a tree. Intuitive and easy database objects handling ­ for example, table creation or modification is not via too long SQL­command writing and via visual dialog which is able to choose types and names of columns.

Next is a handy SQL­editor. SQL queries creation by visual designer. Explain the plan of a query execution. Also the possibility to export the result set of query executions. Beside it there is the opportunity of data import. I am often faced with this necessity when I got CSV­ file with datas import into the database. Nearly all modern databases have storage code support. The debugging makes the development process more simple. That's why the support of this process in GSQL is very important element in such functional. Of course, any process of development has its own mistakes so the functional of the administration and the monitoring is important. For the functional extention must be plugins support.

The Common Layer Is The Evil For DEV'nt Tools

I had released the first public version of the GSQL project since last year (2008) in December.So after it I was constantly asked about not using ODBC. If my project is point at GNOME desktop integration, I'll not use the exist library (libgda) to the database accesss (libgda is the part of the GNOME­DB project). To answer these questions let's see the next picture:

You can see the scheme of the high level design of the development tool using the common layer for access to the database. The common layer in this case is a universal set of functions for SQL query executions. As a rule it is ODBC, JDBC or QSql (a part of QT framework) and so on. It is a very usable for the access to databases. But as you know any unification leads to the infringement of the functionality. DBMS functions would be inaccessible. Have you ever seen the professional development tool for ODBC? As for me no and I suppose you too. Why? Actually, the common layer in the development environment is a stopper not only for some DBMS­-specific functions, but also a stopper for the data manipulations. The work with them is too complicate or theoretically impossible.

The stopper for the data manipulation:

• LOB (CLOB, BLOB)
• Composite (complex, record)
• Array
• XML

... and many other.

The stopper for the DBMS-specific functions:

• Database Change Notification
• Asynchronous Command Processing
• Statement functions
• Admin functions
• Session settings

... and so on.

The HLD of GSQL

What way can we produce the universal environment and not to loose the functionallity? Let's see the next picture:

Here you'll see a high­level design of the GSQL project. There are 3 components here: The first one are Engines . They supply with direct access to databases (blue colour) Also in GSQL they integrate as graphic user components. For example, the tree of the database object is fulfilled with engines. Common usage is a component same as the ODCB layer. The execution of SQL­queries is going through this interface. The SQL­editor is used this functional. Plugins are the components which are extend the functionallity of the GSQL.

As you see from the scheme that the engines are the same as the plugins.In fact their difference is in destination. They realise the direct access to databases, give grafic interface for the operations with objects and give the possibility to operate with the base through the GSQLCursor. And as I've already said the GSQLCursor is ODBC analog for its functionality.