By jan.stoeckler on

Hi,

after stumbling upon the Gladius DB project, which seems to me to hypothetically work with Drupal instead of a MySQL database, i was wondering whether you could point me in the right direction as to where to start.

Description from sourcforge.net:

The most efficient flatfile database engine written in pure PHP, it is compatible with a subset of intermediate SQL92 and does not need any additional library! It perfectly understands SQL (also MySQL variant) and is also supported through ADOdb Lite.

And a description of a possible implementation:

Gladius DB engine can be used as stand-alone (including gladius.php) or with ADODB lite ( http://adodblite.sourceforge.net/index.php ) using the supplied driver gladius_driver.inc. If your databases' folder is not the gladius.php's folder, set the variable $GLADIUS_DB_ROOT before including gladius.php or calling ADODB's AdoNewConnection(). Example:
  global $GLADIUS_DB_ROOT;
  $GLADIUS_DB_ROOT = '/home/usr/databases/';
  
  include 'gladius.php';
  
  $G = new Gladius();
  
  $G->SelectDB('database_name/') or die;
  
  $G->Query('CREATE TABLE hypsin ( base FLOAT, root FLOAT)');
The above example will create a table named 'hypsin' with two fields of type float in the folder 'database_name', which must already exist.

I realise a flat-file database might not be a good idea for large sites with thousands of nodes, users, comments etc. However, it might make possible using Drupal in environments without MySQL support for smaller sites. Of course, one could use less feature-rich flat-file-cms solutions, but once you get accustomed to Drupal, you don't want to go back to those, not even for the simplest of projects.

So I guess my questions are: Is it worth considering? And if so, where do I start? How do I get Drupal to connect to this Gladius DB-database?

Thanks so much!

⋅ Categories: Drupal 5.x, Drupal 6.x

Comments

jan.stoeckler’s picture

jan.stoeckler
he/his
Primary language German
commented

I was hoping somebody could point out to me where best to start?

Would I have to design some kind of database abstraction layer, or could i use or modify the one provided for MySQL databases?

quasimodal’s picture

quasimodal commented

I find this to be an interesting possibility, but I don't enough about the Drupal database to really advise you on how to do it, except for guess work.

For small shared-host site, Gladius is reasonably fast and the backup couldn't be easier, just download the directory. However, administration tools for a Gladius DB is a very sparse, basically just a text block and SQL queries. Still, the idea is interesting for low-tech sites, for those folks who wouldn't know how to use phpMyAdmin in the first place.

I've spent maybe a day over a few months looking at it and it seems to me that the place to start is in the /includes directory, file "database.inc". The actual interface to the database ( for mySQL ) is file "database.mysql.inc". As I see it, start by copying "database.mysql.inc", saving it as "database.gladius.inc" and changing the code to duplicate the behavior of a mySQL database. Do the same for "install.mysql.inc".

You wouldn't need ADOdbLite because the Drupal database API is handling all that. Instead you would need to work directly with the Gladius base library, invoking functions out of "database.gladius.inc".

There may be some challenges with data types. At some point, it might be useful look at the way the Drake CMS is using ADOdbLite to handle data types in file:

"\adodb_lite\adodb_sql_drivers\gladius\gladius_meta_module.inc".

A good place to start might be with function "db_connect($url)" in file "database.gladius.inc". Once you get a connection, the error messages will show you the way ....

It will also involve altering Drupal base modules. If you do a text search of Drupal for the string "mysql", you will find dozens of ominous-looking functions in the form of:

else {
      drupal_maintenance_theme();
      drupal_set_title('Unsupported database type');
      print theme('maintenance_page', '<p>The database type '. theme('placeholder', $db_type) .' is unsupported. Please use either <var>mysql</var> for MySQL 3.x &amp; 4.0.x databases, <var>mysqli</var> for MySQL 4.1.x+ databases, or <var>pgsql</var> for PostgreSQL databases. The database information is in your settings.php file.</p>

The function assumes that only mySQL or PostgreSQL databases will be supported. There are many hard-coded errors messages of this sort.

So, that's my guess on how the project could proceed.. The project looks fairly major to me, so I'd plan on maybe a solid month of work, including two weeks re-coding error messages and setting up some sort of ['database type'] mechanism in Drupal modules.

I don't have much time these days for a major project, but I'd be able to help a bit.

- Bill Breitmayer

jan.stoeckler’s picture

jan.stoeckler
he/his
Primary language German
commented

Hi there,

thanks for the reply and your expertise. I'll be looking further into the matter after my current projects are done and allow me to focus on this issue.

Thanks again! I'll be following your approach.

quasimodal’s picture

quasimodal commented

I've been thinking about ADOdbLite.

It hasn't had a release in several years and appears to be unsupported, so that's not good. On other hand, it works well and runs pretty fast. It might be easier and less work in the long run run to interface the Drupal hooks to ADOdbLite functions, as opposed to linking them directly to Gladius functions. It would also have the benefit of being able to support a wider range of databases, more or less for free.

Another problem with ADOdbLite, in addition to being unsupported, is its size. The download is about 1.4 MB, but if the only about 190KB is core code in the root directory - the rest is addons, documentation and drivers for each database supported. The Gladius driver is about 32K. So the total size for the ADOdbLite component would be about 220KB. The code for Gladius is about 160KB. Allowing about 50KB for the Drupal interface, that would give a grand total of about 430KB. That's a pretty big module. In fact, I'm not suggesting this, it's just the naive approach.

A better idea is to take ADOdbLite and build it onto the Drupal interface. If you took only the functions you really need out of ADOdbLite and put them into the Drupal interface module, it might increase the size by about 50K for the core files, that is:

adodb.config.php
adodb.inc.php
adodb-datadict.inc.php
adodb-error.inc.php
adodb-errorhandler.inc.php
adodb-errorpear.inc.php ?
adodb-exceptions.inc.php

So the Drupal interface would be about 100KB, plus about 32KB for the Gladius driver, that would mean about 130KB for the a Drupal download only supporting Gladius. The Gladius module is still about 160KB, for a grand total of about 290KB. It's still not a small module, but now it also provides a framework for other databases, including ODBC and MSSQL. Drivers run from 30 to 50KB each.

I think it's a better approach than trying to interface to Gladius directly. Since there seem to be no future releases of ADOdbLite planned, you don't have any version synchronization problems. Still , it's a lot of work. You might even run into bugs in version 1.42 that were never fixed.

You probably have encountered some of the other discussions about Drupal flat-file database support, such as:

http://groups.drupal.org/node/10282.

Support for databases other than mySQL and Postgres may eventually become a critical factor for the continued growth and acceptance of Drupal. So there are some larger issues floating around that may impact future releases of Drupal, particularly in database abstraction.

http://groups.drupal.org/node/8855

I'll keep posting here if I can think of a better approach.

- Bill

"Design like talk is cheap, thank god !"