Last September I decided to make a switch from the ADOdb Database Abstraction library to a smaller more memory efficient alternative. Of course, I’m talking about ADOdb-Lite created by Panama Jack (the guy in charge of Alien Assault Trader’s development). Making the switch was not done lightly. ADOdb is an extremely popular abstraction package with a lot of solid support and features. On the switch side it hogs memory. ADOdb-Lite‘s claims to reduce the memory usage substantially while still offering a similar (though reduced) feature set was very attractive.

The switchover overall has been worthwhile. Its worth noting that at the time ADOdb-Lite was a very new library so it took some time to settle down into a stable form. Since that time I’ve reported two bugs and requested one function change, and seen other issues like the unexpected return of full arrays not associated arrays (no numeral keys) a few versions back resolved.

Some ADOdb features are yet missing. There are no Caching functions, which removes the possibility of caching results to file. Now PanamaJack justifies this by noting in-memory caching features of MySQL – incidentally Postgres has something similar. Lets talk DBMS’s in general before justifying everything with MySQL. I rarely even use MySQL. But at the moment its not a concern for me – to be honest the library is open source, so if I do need it I’ll hack it in there with the nifty module system.

Also missing is the Performance Monitor offered by ADOdb. Again this is one of those extra rarely used features. It is quite useful, but I’m not certain how in-depth this was originally integrated into ADOdb. This doesn’t particularly bother me since I use ADOdb-Lite as the abstraction layer in a Data Access object – I can fit in a perfmon clone without touching the ADOdb-Lite source code. Of course it’s pointless at the moment given a DAO does not necessitate optimised SQL. Unfortunately its a complex item to add to a clearly defined DAO-TransferObject or ActiveRecord setup without turning the DAO into a collection of transaction scripts…

Another small niggle in the system are the potential typo-style errors. ADOdb-Lite was either developed on a plain text editor, or a non error reporting IDE. Eclipse still complains a lot about ADOdb-Lite having notice level errors, and in earlier versions potential parse errors. Small niggle, I have a preference for IDE quality assurance as a first line error pickup mechanism. The library does ship with tests, which although not Unit Tests do a fair job of exercising the Library. They’re imperfect however for a full test suite – they can’t cover all DBMS’s supported at one session. Hardly the developer’s fault – it’s just the nature of an abstraction library.

Overall ADOdb-Lite is definitely worth a look at. It does a fantastic job of reducing memory usage, enough that it makes up a substantial percentage of QSE’s memory use reduction over QS2. It’s matured over the last half year to a stable dependable library. It lacks some features of ADOdb, but these tend to be small-use features most developers wouldn’t even touch. Of course that may be a bitter pill for some developers to swallow. A good trend is a steady pickup of ADOdb-Lite – I’ve seen a few projects make the conversion recently.

In summary, if you’re expecting to develop an application for public consumption in enviroments that may include non-accelerator enabled shared hosts then ADOdb-Lite is a solid alternative to ADOdb. It’s still maturing, and has some small issues but for most common use-cases it’s worth looking at.

Related posts:

  1. ADodb-Lite 1.14 Released
  2. Escaping in ADOdb; does it exist?
  3. Another ADOdb Update
  4. More ADOdb-Lite Bugs for the grinder
  5. Transaction Support for QS