So I'm working on a php db abstraction layer for pff - yeah yeah, everybody writes them I know. The three biggies are adodb, pear-db, and metabase/mdb/mdb2. And they suck.
Normally I'm not really nasty about other people's php... The nifty thing about php is a single problem can be solved a hundred different ways depending on your mood, one of the reasons why libraries aren't as in vogue in php as in other languages. But if you do an application and you want the ability to easily switch out the backend, you have to write an abstraction layer. And the three biggies are just that...biggies. Secondly none of them are designed just for php5. Notice I didn't say they don't work with php5, just that they don't leverage the features available to the fullest. So I've been fiddling here and there with an, as lightweight as possible, php5 dependant, db abstraction layer. Wow that's a mouthful. And I think I've found what I wanted. I've modeled most of it after pdo, I see the future and don't want to be left in the dust...although with some things fixed for my tastes :)
First of all, it works on the two classes for everything system. I have an abstract driver and an abstract results/statement class. The reason for using a base class is to control the api and throw boring repetitive code in one place. Yeehaw. Anyway, then there's a driver and result class for each db needed. I've been trying REALLY really hard to keep the code size down. And still keep the amount of features way up. Yipee-ki-yeah. Today I got to keelhaul the mysqli statement class into shape, that was fun. And I mauled a really ugly (or pretty depending on your pov) regular expression into being, so not only can any driver emulate both named and question mark parameters, but drivers that natively accept only one or the other can force named to question mark AND force question mark to named if needed. I keep a map of position to name for named to question mapping that gets referenced when binding params... That was fun :)
I have the mysqli driver down to about 500 lines or 16K (that includes extensive phpdoc comments, I'm a comment whore...) but I still need to add management methods so I can use xml files to create/alter db structure, a nice dump feature, etc. The result class is about the same size but is about 2K smaller - and I have some stuff I have to shuffle around back into the abstract classes. Still, I'm pleased with the results. And it has LOTS of features :)
I'm just wondering, as I have been wondering, why mdb2 is so damn big? I mean, adodb is big but it's api is bulky and it has three million features. DB has been steadily improving, but it's short on features... So here I am reinventing the wheel. Oh well, I suppose that's the insanity that is me. And using a pdo similar api will make life pretty easy when the world catches on to how lovely 5.1 is :) Actually, I've been using it for, gosh...a long time.
I tried to write a php4 app like two weeks ago and gave up. I literally couldn't do it without going nuts. php5 is also really stable. I've been running it as an apache module AND as an isapi on windows, of all things, at the same time and the only extension that can crash it is xdebug :) Ah the irony. However, it's not exactly getting a high server load but I run some pretty esoteric stuff while I play.
Anyway, I'm of the opinion that the world probably doesn't need another db layer, but since mine is getting plugged directly into pff and the wheel suddenly has spokes and a rubber outer rim I don't feel too bad for "reinventing" it.