Wirtting query in reserved word safe: any possible solution?

Reserved word conflict is an always pain for multiple DB backend supported system: Drupal also face this for many years (e.g. http://drupal.org/node/371, since June 30, 2002). This is the most complicated bottleneck for daily maintenance and introduce any new DB backend to Drupal: whenever existing DB vendor change their standard, we need to follow it; whenever a new DB backend introduce, another set of reserved words are coming in, too. There is many possible solution, e.g. prevent use of ANY reserved words based on requirement of ALL supported database engines (as like as Moodle's implementation); BTW, as this solution will left issue as ALWAYS OPEN, I am not going to discuss within this review. Another possibility is the use of escape characters, e.g. `` for MySQL, "" for PostgreSQL/Oracle/DB2 and [] for MSSQL. This approach is widely used for many successful projects, e.g. phpmyadmin, phppgadmin, Oracle/DB2/MSSQL EM. The primary consideration is: How to implement this syntax for Drupal, which is simple and elegant for both end user and DB abstraction designer? For sure that we will need some update for existing Drupal queries syntax, where the ultimate goal is query will finally present as following example before process by PHP database connection (e.g. SELECT batch FROM {batch} WHERE bid = :bid AND token = :token from line 15 of includes/batch.inc, CVS HEAD, rewrite with TNG DB standard). In case of MySQL, after translation it should looks like: SELECT `batch` FROM `batch` WHERE `bid` = :bid AND `token` = :token I will discuss different syntax change approach, based on: a) user experience, b) similar to ANSI coding style, c) backward compatibility, d) backend complexity, e) overall performance and f) workload for syntax conversion. A simple marking will be given for each item (e.g. good/functioning: 2; fine/not bad: 1; poor/not functioning: 0) so we can have some simple idea between different proposals. Here is a quick rundown of my review:

Forward a message but still leave a copy on the server?

I am using Debian etch for production, plus Exim4 with per user ~/Maildir support. Since I hope to forward each user message to their own public email for backup, Procmail FAQ give me a useful example. First of all, check if your Exim4 have ~/.procmailrc supported, which usually already there. Find the follow code snippet from /etc/exim4/exim4.conf.template: ##################################################### ### router/700_exim4-config_procmail

A new day, a new life, a next generation

Yesterday is my last working day for HKU CITE. After 3 annual holidays, I will in a new position on Monday. It is a secondary school and I will work as an IT Officer. Most duty and position are similar as now, but coming with better location, job title, working hour and also salary.

PostgreSQL 8.3 on Debian sid mini-HOWTO

This mini-HOWTO will guide you though the installation of PostgreSQL 8.3 on Debian sid. After install initial packages, you will need to create and configure both user account and database, which Debian installation script will not do for you.
Before start I will assume you have a complete installed and functional Debian sid box on hand. If you have no idea about this, please refer to my other article for more details.
This document is a refine and trim down version of my legacy artical which target for Debian etch. Most procedure are shared so you may also able to apply them in case of Debian etch.

Prevent '*Zone.Identifier*' files generate by WinXP SP3 and Samba3

My Samba is working fine before but some days ago, it keep on generating some '*Zone.Identifier*' files, e.g. DskPerf.zip:Zone.Identifier:$DATA, when copy file from WinXP SP3 to Samba. I can't delete them from both Windows and Linux, and I don't even understand why it come out suddently... Finally, openSUSE forum give me a workable solution (http://forums.opensuse.org/network-internet/387779-samba-file-transfer-creates-zone-identifier-files.html). Just add the following line to smb.conf: vfs objects = streams_xattr

Drupal 6.x + PDO_OCI: finally work together

After put down my multiple database backend research for Drupal among past 4 months, now finally get Drupal 6.x and PDO_OCI working together... It is all about my incorrect pdo_oci driver implementation... The progress is now available in here.

What is the bottleneck?

PHP debugging...

Finding way to debug PHP, since pdo_oci keep on crash with Drupal (Siren) installation and operation. Seems to be problem of BLOB insertion and deletion. P.S. same code base are function with oci8 (i.e. PHP and Oracle are both function) and pdo_pgsql (i.e. programming logic for Drupal + PDO is function)...

Remember to compile PHP with --enable-debug and --enable-xdebug options. Still don't know how to play with vim + Xdebug...

PHP + Xdebug:

Still fighting with annoying ORA-01461 + pdo_oci...

As like as case before, Siren + pdo_oci is still buggy with ORA-01461 during installation. Well, since pdo_oci doesn't update since 3 years ago (http://pecl.php.net/package/PDO_OCI), for sure that the case will not have any change... Anyway, this page give a very detail idea of the problem (http://littledan.itpub.net/post/6400/270539). When checking with script provided in document, I found that some table is now buggy with the problem:

Siren: dev check list + bug list + footnote


Subscribe to Edison Wong RSS