Fabrizio Balliano

Zend Framework has a quite impressive Zend_Date and Zend_Locale modules which finally do things we needed 4 years ago with MerlinWork and then P4A, like normalizing localized dates and parsing the Unicode’s Common Locale Data Repository but I think we still need a good calendar module that would do the things that Pear::Calendar does now. I’ll post an issue to Zend ASAP.

PDT is the new PHP development plugin for Eclipse, officially recognized and supported by Eclipse.org.

PDT 1.0 is out today and I’m upgrading right now, I just found a cool new feature I want to share with you all, look at the screenshot (I was committing a small file), focus on the red zone and look at the way DIFF is shown:

Can you see that within the same line, changed chars are highlighted? Cool hu? Now everyone can really find the differenced within the same line, not just the whole line! I really like that :)

• I’d hire 5 programmers to finish PHP unicode support in 2 months
• I’d hire 5 programmers to clean up the database drivers and fix some PDO problems within 4 months, so also PHP could have a great DB interface like jdbc or ado
• I’d hire 2 programmers to add a full abstraction layer to Zend_DB
• I’d drop the old Zend Studio and focus on Eclipse PDT
• I’d start a PHP development blog, people need to know where developers are going

This is just my opinion working every day with PHP for many purposes since 7 years.

PS: Surely also SOAP support needs attention but it seems they’re working on it.

Once upon a time PHP had several different DB drivers such as:

• mysql
• pgsql
• mssql
• oci
• sqlite
• odbc
• informix
• firebird

Later came

• mysqli
• oci8

and we already had duplicated drivers (also if they have some different optimizations/features)

Later came PDO and we had

• pdo_mysql
• pdo_pgsql
• pdo_mssql
• pdo_oci
• pdo_oci8
• pdo_sqlite
• pdo_odbc
• pdo_informix
• pdo_firebird

so now we have 4 drivers only for oracle (oci, oci8, pdo_oci, pdo_oci8) and 3 for mysql (mysql, mysqli, pdo_mysql) and anyway every driver is at least duplicated.

I don’t think this is the right way to go on, if PDO is here to remain, first all bugs in pdo should be solved and PDO features should reflect the single driver feature (I wrote about about that yesterday), then old drivers should be removed. Duplicated oci/oci8 driver should be unified too.

Now the situation is confusing and it’s difficult to test things against different drivers, tracking and solving bugs.

There are mainly 2 PHP abstraction layers out there:

• PEAR::MDB2
• ADODB

I used both for long time within P4A and the conclusion is that none of them is good enough, because of feature lacks, bugs, communication difficulties with the team. I have to say that MDB2 code is much clearer.

But there’s something interesting coming out from the enterprise world: Zend_DB, really well written and planned, feature rich and with a good team behind, but as the team says “it’s not a full abstraction/portability layer” so why not fill the hole?

What’s missing:

• sequence emulation, creating a table on DBs where sequences are not implemented. PEAR::DB already did it since years. This approach is not the best if you look for performance but it’s perfect for portability.
• metadata retrieving from a query instead than a table. We can read columns and metadata from a table but what about a query such as “SELECT * FROM table JOIN other_table”? We need to know which fields are returned, the data type and the table name.
• metadata mapping between different db engines, building an abstraction layer between different datatypes on different db engines, something mapping MySQL tinyint(1) to PostgreSQL::boolean and so on. MDB2 and ADODB already do that thus adding this feature won’t be too painful.

I’m also thinking about the redundancy of db adapters in PHP5 but that will be the subject of another post…

It seems to me that none in the world needs to get meta-info from a query like this:

SELECT * FROM table1 JOIN table2 ON (table1.id=table2.id)

I need to know from which table are the returned columns from. That’s not possible. It was possible with some old PHP DB drivers (not for all and I can’t understand why) but it’s not possible with PDO (and also Zend_DB does strange things about that but it’s very limited).

Let’s look at the situation, PDO has the PDOStatement->getColumnMeta() method but:

• This function is EXPERIMENTAL. The behaviour of this function, the name of this function, and anything else documented about this function may change without notice in a future release of PHP. Use this function at your own risk.
• Not all PDO drivers support PDOStatement->getColumnMeta().
• withit the returned data there isn’t the table name

I filled a bug some time ago and some developer add that feature for MySQL but they don’t understand that it’s needed for every DB adapter and it was already done by some old functions.

Maybe no PHP developer need such kind of abstraction.