edin.no-ip.com

Current progress

Well, after the development of 6 initial database drivers for Siren 1.x (Drupal 6.x) (including mysql, mysqli, pgsql, oci8, pdo_mysql and pdo_pgsql), I have move my focus to pdo_oci and ibm_db2 after Siren 1.0 RC2 (Drupal 6.0 RC2) release. BTW, I face some difficulties:

1. pdo_oci not support CLOB handling. CLOB can function correctly with oci8, but it is still an incomplete function for pdo_oci, based on message from Christopher Jones (Thanks once again, about point out PDO v2 is now coming).

   I may convert ALL CLOB field as BLOB in both case of Oracle driver for Drupal (or better says: use BLOB for node body, node teaser, block body, etc), and so simply forget ALL ABOUT CLOB; BTW, this will introduce another problem that we may not able to handle node body as our existing implementation with TEXT, in case of MySQL/PostgreSQL.

   This would need some suggestion: would we accept changing the (some) use of TEXT (says D7?) in case MySQL/PostgreSQL, into a BLOB handling? For sure that we will lost some functionality, but this will greatly improve cross database compatibility as MOST database support BLOB (but not CLOB).

2. ibm_db2 gone a bit crazy. Most likely both db_fetch_array() and db_fetch_object() should be functioning in Siren 1.x HEAD; BTW, whenever I try to load the detail view of a node, an error message is always pop up, and complain about db_fetch_object() (only one message).

   Note that there is not only a SINGLE call of db_fetch_object() from a node detail page, but I just get ONE error message from db_fetch_object(). I guess it is not about the implementation of db_fetch_object() but something else. Maybe due to lossy DB schema, maybe due to lossy core code implementation... Well, I need time to figure it out...

Next target

On the other hand, I am now having a look about SQLite. Some people claim in mailing list that we may even DROP PostgreSQL support from core (since lack of tester), on the other hand ADD SQLite supporting in D7.

I think that is a good idea for adding SQLite support, because 1. it is lightweight for small loading site, especially for personal blog, 2. it is simple, as integrated into PHP as library, 3. it follow the SQL92 standard (MOST IMPORTANT!). By supporting SQLite (== most SQL92 standard), we can easily limit our core queries standard into THE LOWEST COMMON among different databases, which means GREATLY IMPROVE cross database compatibility!

BTW, the drawback is very simple: we will need to give up some advance feature besides SQL92. E.g. core queries should write in common standard, without any MySQL/PostgreSQL specific/advance features. I will seems this as an evolution but not a feature trade-off: we grain a better cross database compatibility (== more choice in database backend), and so able to overcome some problems which should be better solved by database vendor, but not our database driver API, e.g. clustering and replication.

Moreover, by ADDING SQLite, I can't see the point for DROPPING PostgreSQL support. It seems funny for this conclusion; but if we are able to write core queries in common standard (but not MySQL/PostgreSQL specific), there is no point it will cause problem in case of PostgreSQL, and need special PostgreSQL testers for testing its correctness. We may also employ this idea for other databases, says Oracle, DB2, MSSQL, too.

Well, seems a bit out of topic. The main point is: I will try to integrate sqlite and pdo_sqlite into Siren project, and so re-contribute it back for Druapl 7.x whenever it is open for public development. The common base build by Siren is quite solid, and so shouldn't be too difficult for adding SQLite drivers into it ;-p