From Apache OpenOffice Wiki
Jump to: navigation, search

Better and simpler infrastructure for database drivers

This is for the moment just a brainstorming page. This is too unformal at the time being to be converted to a real "issue" in issuezilla or a specification.

Idea 1: have a "drivers loader"

Summary: currently, most database drivers are divided in two libraries:

- a small part that verifies that the conditions are met to load a given driver
- a big part that will in turn dl'open the needed libraries and do the real job

The idea would be to merge all the small "loader" parts

Pros: efficiency, reduce number of libraries

Cons: against modularity

Idea 2: have "evaluation trees" in addition to current SQL syntactic tree

Summary: currently, the drivers that have to analyse the SQL syntax use the SQL parser, which does all the dirty work of checking grammar and tokenizing, but they are on their own when it comes to running the request. Perharps the runtime in-memory trees for selections and sorting of the kab driver could be reused.

Pros: simplify code for drivers like the evolution driver

Cons: uncertain feasability, because the way that you run a request might depend to some extent upon the underlying database.

Idea 3: have a "generic driver"

Summary: currently, there's a lot of drivers which duplicate a lot of code. It could be done in several steps, starting with a basic infrastructure for the simplest drivers which mainly differ in the code to access the concrete table data, and ending with drivers that are different in many aspects.

Imagine, for instancem a driver which is completely implemented except the table data access. Now some component could instantiate this driver, and pass it an XTableProvider and an XTableDataProvider (or so) interface, which allow to enumerate existing tables, and retrieving their data. This would, in a first step, allow get rid of today's drivers for Calc, flat text files, and the KDE address book. Additionally, it would tremendously ease the writing of new drivers which just need readonly access to flat tables.

In a next step, this driver could be extended with update capabilities. So, it would allow to be parametrized with some kind of XTableDataUpdate interface. This step would allow to get rid of the dBase driver, too.

Step 3 is to implement support for some XSort/XFilter (or so), which passes the responsibility for filtering/sorting the table data to the concrete backend, instead of doing this client-side in the generic driver. Step 3 would allow us to get rid of the Evolution Address Book and the Mozilla/Thunderbird/LDAP drivers.

Further steps would be more difficult, since from there on, drivers differ in much more aspects. We would need to abstract from those aspects, and hide the differences behind some generic interfaces. It might well turn out that this is not worth it anymore, since the abstraction API might become as complex as the SDBC(X) API already is, so there would be no point in creating it.

Pros : remove code redundancy Cons : major rewrite

Idea 4: have a "drivers inheritance tree"

Summary: basically the same as idea 2, but with drivers inheriting one from the other, rathing than inventing new shared UNO interfaces. The inheritance tree could look as follows:

database driver

  +--- SQL driver ---+--- MySQL
  !                  +--- PostGreSQL
  !                  +--- HSQLDB
  !                  +--- Adabas
  !                  +--- ODBC
  !                  +--- JDBC
  !                  +--- ado
  +--- API driver ---+--- File driver ---+--- Flat
                     !                   +--- Calc
                     !                   +--- dBase
                     !                   +--- XML FIles
                     +--- Mozilla
                     +--- Thunderbird
                     +--- Evolution
                     +--- KDE

Pros: ease of writing new drivers Cons: Major rewrite too

Actually, this is kind of complementary to the previous idea. That is, implementing the one would probably remove the need for other.

Also, there are people saying you should favour composition over inheritance, and I lately tend to agree to them :). That is, instead of building a complex inheritance hierarchy, it might be more elegant and future-proof to create a number of components which can be plugged together.

Personal tools