Database Abstraction Layer

Much was discussed about implementing a Database Abstraction Layer (DAL) in the Nucleus 5 core, including the eternal dilemma “Pear::DB vs ADOdb”. Alternatively, we could fully implement a general DAL or code/improve the current Nucleus Database-API.

Regarding “Pear::DB vs ADOdb”, some developers favored ADOdb, while Pear::DB was not 'strongly' defended by anyone. This was a long discussion and maybe it's time to stop waiting for a Pear::DB defender and decide, now, for ADOdb. Of course, there is also the option to improve the internal API, but this was more an option to reduce changes in Nucleus 3.x core, since we are talking about a big refactoring. I feel there is a general consensus in the air to use ADOdb. If you disagree, please share your thoughts here.

→ Read more on this Nucleus Forum topic.

(by xiffy)
“If you want a short-term solution to offer some kind of 'generalized' sql to 'any' db. either PEAR or AdoDB is the way to go. And if you decide to do either one of them, you will run into problems which you wouldn't have with the other one. But if you choose the other, it would have been the other way around. So which on to choose (or say we do it the 'half but fast solution which is having the sql_ functions in place of our own). here is no way you can have all current code in plugins running and yet have them channeld through some magic 'query-parser'.

Making the choice for a DAL already available with all of it's flaws and misbehaviours has at least one huge advantage, which is support and availablity. I'm sure that if we give ourselves time, and focus on it we could write some briliant DAL ourselves that would cover everything we do at the moment with mysql.

But if we invest that same amount of time in our already written code we will maybe make a better code-adjustment to the whole core which, maybe could help us to an easier transition to some xml-storage if would want to go there after that.

Reading that php5 does not support the mysql_ functions by default was a bit of a suprise for me. But that 'prob' could be solved in a couple of lines of code in globalfunctions (i guess / hope).

But again learning from what your coding for either implementing a standard DAL or trying to recode as little as possible and coding a 'clever db layer' yourself. I would opt for the first one, multi db support, generalized layer.”

(by admun)
I think my major concern in regard to having a DAL are: 1) backward compatibility to existing plugins 2) performance 3) footprint (size of code inflated by DAL)

I think for Nucleus 3.x, we should stick with the existing mysql_ API. I think the work needed is to mod (please correct) and add support for mysql_ to able to adapt to php5 (which is w/o mysql_ functions by default) and MySQL 4.1 environment.

On the same time, we should started cleaning up plugins and encourage plugin writers to use _only_ the internal mysql_ API, so migirating to PHP5+mysql4.1 should be painless, hopefully. I saw a lot of plugins still use sql_query.

For Nucleus 5, I agreed it might be better off to use a DAL since it saved some work while we refactoring the code. My assumption here is performance and footprint is not compromised.

{Mike Coughlin}

Re-inventing wheels, like widely-used data-access layers, could be a mistake. Re-inventing gives up standard (plug-in), modular and widely-supported approaches to complex functionality, involving multiple (database) vendors, including performance tuning and other future development of such functionality.

And, for what benefit? … to avoid untangling what might have been implemented in a more layered, modular fashion in the first place? Ok, how `bout untangling it, now, rather than adding even more complexity, duplicating functionality which has already been highly refined by other specialists, closer to that (database) functionality?

This is part of the plans for Nucleus 5. Read more about the project.