Smoking toooooo much PHP

Ever since PDO was proposed, there have been warm fuzzy feeling about it's iminent arrival. I hate to say, though I fear it could be the biggest mistake PHP ever makes.! (well I guess among the worse).

That's not a lightweight statement, and I'll fire of the disclaimers, before I go any further.

• I'm working on an alternative at present.
• I know the authors of PDO personally, and I probably owe them a drink for dissing the work.
• From what I've seen of the code in PDO, it's pretty damn good.

So what you may ask is so wrong with it?

The major issues I have with PDO are

• Reuse, recycle...
  
  When there was at least 2 capable, cross platform database libraries available. Rather than examine if they where a feasible option, it was decided to go off and start from scratch.
  
  Having spent quite a time working with libgda, probably the best library available to do this, It has a 5 year head start, fully tested, and is considerably more feature rich than PDO will ever be.
  
  PDO seems to be slowly gaining backends, however, It's a long way from having as many as libgda. And for each of the features missing in PDO, It will take time to ensure they are enabled in all the backends, let alone fully tested.
  
  
• Copying C is not always a good idea..
  
  The worst features of PDO is variable binding (similar to pointers). This is what could be regarded as 'minefield programming'. In some of the worst wars in history, army's laid mines all over stratigic borders, so that the oposing army would be delayed in crossing. What happened after the war was a tragic travasty, the abandoned minefields started injuring innocent civilians.
  
  The way variable binding is done in PDO mimics this behaviour, while it achieves the goal of making updating rows relatively simple, It has the significant downside that it makes code unpredictable, splattering variables, which if changed may update a database, without making it clear and simple that this may occur. This whole issue should have been dealt with by using objects to represent database rows, and only make these usable as 'updateables' (see the introduction to DataObjects) which is exactly how DBDO was designed.
  
  
• Cool features dont always make great features.
  
  Iterators where introduced with much fanfare in PHP5, using foreach on an object that implements the iterator methods, and result in a fetch operation on every foreach. The simple example below illustrates the crux of the problem. (and I've already seen people pastebin iterator code, and you really are making wild guess as to the intent of the code)
  
  Without sensible variable names, this rather confusing code easily evolves into complete jiberish..
  

  foreach ($pdoresult as $row) {
  ....?? is $row an object/array/or something else. ??
  }
  
  compared to the clarity below
  
  $do->query();
  while ($do->fetch()) {
       $data = $do->toArray();
  }
  
  

  
  While I believe you can still use PDO without using iterators, They do lie at the heart of the problem. I dont know if it was an off-the-cuf remark, but It appears that PDO started as a proof of concept for using iterators on Databases, and as it evolved became a limited Database abstraction layer, which leads into the last issue.
  
  
• Design by evolution, at the beginning or end.
  
  I dont think I've ever come away and designed an interface correctly the first time, by now DBDO has a long history.
  
  
• Started off as Midgard's Data Model emulation in Midgard Lite
• dboo, was an improved version, introducing query building from object vars, primary key knowledge
  
• DB_DataObject, introduced a generator, simple data type knowledge, PEAR DB backend, Joins, and alot more.
• DBDO takes DataObjects as a base, removes alot of cruft that has built up, and at the same time introduces extensive datatype support, lazy fetching.

I'm sure there are some valid reasons why DBDO could not stand up as the next generation Database library for PHP5, but I wonder seriously if those are less significant than PDO's.

• Win32 Support
  After considerable work over the last month, this is pretty much solved. (Although I only bothered building mysql/postgres for win32, to continue the process should be pretty simple.). Given this work already, the amount of effort to make it 'enterprise ready', is pretty minimal now.
  
• Too many libraries?
  Libgda has a midsized dependancy list, although this is not that major compared to libxml2, which is now part of the standard distribution. Currently DBDO needs
• libgda (obviously)
  
• libglib
  
• libgmodule
• libgobject
• libgthread (maybe not necessary)
  
• libxml2 (used by PHP's xml extension already)
  
• libxlst (used by PHP's xlst extension already)
• iconv (used by PHP already)

Not sure if this blog will change the fact, but by not using libgda, I think PHP is missing a huge opportunity to stand on the shoulders of giants, and get a world class Database backend, with a limited effort.

This week saw an amazing jump forward in internet banking security in Hong Kong, HSBC's security rating jumped from bungling idoits to have trained chimpanzees. Kind of reminds me of Microsofts attitude to security. Features first, until something starts going wrong.

HSBC Hong Kong, probably overflowing with compaints from people who had been caught out with phishing attacks, and transfered their life savings to some nice guy in nigeria. Finally put a stop to transfers outside of registered accounts..

I had quite a long conversation 6 months ago, when I though It might be quite usefull to monitor my bank account on-line.

"So can I sign up for a read only account?"
"Sorry we dont offer that facility..."

Well duh, yeah, they only offered the "give your money to compete strangers" type of facility..

Of course it's pretty damn obvious that to do internet banking properly, any kind of transaction should be confirmed via SMS or simple automated phone calls.. But since the banks only wanted to say 'we have internet banking', rather than actually doing it properly. We end up with a plug and prey banking system.

I bumped into an 'unnamed source' involved with IT at HSBC, while he didnt know much about the internet farce there, he did reveal something even worse.

HSBC HQ in London have decided to go with Windows XP for their next generation ATM's. Well, in kind of nice to know that hong kong hasnt got a monopoly on stupid decisisions.. They did have a few redeaming facts, it was being written in Java.. (I bet it would quicker/simpler/more reliable in PHP/Python.. - but suit's and smart IT dont always go together).. And they did retain the option to use Linux. (although their major suppliers appear to have been slacking on delivering that option)..

Maybe it's time to start moving the savings to a safer bank.. like sticking it under my mattress :)

I mentioned a while back that my new php extension (dbdo) used libgda, and that i ran into a roadblock, that libgda was not available on windows. Well, after quite a bit of work, that is finally solved.

For those not interested in the how - it's available here
libgda for windows

IMPORTANT: you must be unzip the files to C:\libgda (so the providers are in C:\libgda\providers\*.dll)

Note you need the dll's from the following files
(use http://www.gimp.org/~tml/gimp/win32/downloads.html if any of these are out of date.)

http://www.gimp.org/~tml/gimp/win32/glib-2.4.5-20040903.zip
http://www.gimp.org/~tml/gimp/win32/libiconv-1.9.1.bin.woe32.zip http://www.gimp.org/~tml/gimp/win32/gettext-runtime-0.13.1.zip

from ftp://ftp.zlatkovic.com/pub/libxml/
ftp://ftp.zlatkovic.com/pub/libxml/libxml2-2.6.14.win32.zip
ftp://ftp.zlatkovic.com/pub/libxml/libxslt-1.1.11.win32.zip
ftp://ftp.zlatkovic.com/pub/libxml/zlib-1.2.1.win32.zip

for mysql
http://mysql.mirrors.pair.com/Downloads/MySQL-4.0/mysql-4.0.21-win-noinstall.zip

for postgres
http://www.hagander.net/pgsql/win32snap/postgres_win32_7.5_devel.zip


While I doubt I'll ever personally use the thing, It has been quite interesting building it. After trying out a few compilers (including MSVC, dev-cpp, cygwin) I settled on using mingw and cross compiling on linux. (yes the whole thing is built on linux!), and tested under win4lin.

I did experiment using make/configure, but concluded it was far easier to script the build process in PHP (build.php), there is also a enviroment creator (mkenv.php) which downloads all the necessary components (may need tweaking)

Other than this, there is a little fun involved in getting the mysql backend to build. Based on the instructions on creating a mingW mysql client, you have to follow the windows bit at the bottom, pretty much word for word..

1. download the mysql libs above
2. copy the libmySQL.dll to a windows machine, and run the pexports (part of the mingw distro for windows) to get the def file.
3. copy the defs file to the build same folder as the original .dll
4. run the dll tool eg.
   /usr/src/win32mingw/mysql-4.0.21-win/bin/#
   /usr/src/win32mingw/cross-tools/bin/i386-mingw32msvc-dlltool --input-def libmySQL.def --dllname libmySQL.dll --output-lib libmySQL.a -k
   
5. Try running the builder - you get lots of errors like
   unknown symbol mysql_init@4 ..... mysql_real_connect@16 etc.
6. edit the defs file manually (change mysql_init to mysql_init@4 - matching the prefixes to the missing symbols
7. repeat step 4.
8. if you got all the right @ signs it will build very hapilly.

The other big trick that I spotted from mysql++ was that you need to add -DSYMBOL=int to the gcc lines!! - that's not mentioned anywhere!! :)

Next step is finding if anyone can add dbdo to the build scripts for snaps.php.net