ADOdb
matt_paz - January 31, 2006 - 20:23
Any ideas about why Drupal isn't using ADOdb? Seems like a logical way to increase db compatibility.
Please note, I'm not a PHP expert, so if ADOdb is taboo, please let me know.
http://adodb.sourceforge.net/
yes
I think this would be invaluable. adodb and PEAR now have getAll, getRow, getAssoc and prepared/placeholder statements.
This would be very welcome and easy to implement
We used to use PEAR for
We used to use PEAR for Postgres support, but have changed that since it was too much overhead. Our db compatibilty layers in database.*.inc is very small. I doubt that any other project could provide a similar small layer.
--
Drupal services
My Drupal services
Very small layer, but it doesn't discourage incompatible SQL.
This may be true, but they don't discourage incompatible SQL. People are writing some SQL into modules that only works on MySQL databases.
Sometimes chasing down the problem isn't too hard, but if something like ADODB were in use, it would be an extra impediment to writing incompatible SQL code. I only gripe because when the incompatible code is deeply rooted in the module it give me a major headache to have to dig deep and change it.
I'm currently having this problem with the polls porting code in the phpbb2drupal module.
But speedy
Hm, I know the libraries are small...but are they any faster than ADOdb? I've used it for a few projects. It is a very nice library.
I guess the real question is, how would the 'community' feel about moving to ADOdb in the future? This question needs to be debated to a wider audiance as more DB libraries are being introduced. A lot of work is going into new DB's....but perhaps this work should be going into migrating to ADOdb?
Thoughts?
It unlocks many more database backends.
I'm a very big fan of ADODB. How else can you snap-in a dozen or so database backends instead of just mysql? Frankly at this point I'd even accept PEAR for database abstraction since it's an official part of PHP, even though I prefer ADODB's syntax.
PostgreSQL is supported in a mediocre way overall in drupal right now. I've been submitting patches for it for various modules, but it sure would be nice not to have to do that.
Yes, modules would have to be revised to use adodb/PEAR calls, but I think that more database backends is holding drupal back from wider acceptance.
Anyway, I don't expect this to change the system, but a programmer can dream.
Seconded...
I agree about Postgres support. I love Drupal to death, but it's one of the applications preventing me from switching a large number of sites from LAMP to LAPP stacks.
Coding primarily for MySQL and making accomodations for other databases entails a lot of overhead work, especially for module developers. It would be far more elegant to code to a DB-abstract interface, and have the backend worry about storage. An additional advantage is that developers don't need to install multiple DBs to fully test their code; programming to the abstraction layer will guarantee that their module will work on any Drupal installation. This is a significant benefit.
Another issue is MySQL's unique features. I was told that Drupal doesn't use FOREIGN KEY between tables because it's not supported in MySQL 5.1; I'd much rather see FOREIGN KEYS for the many SQL-compliant DBs, and some sort of emulation in the abstraction layer for MySQL.
What does everyone mean by "PEAR database"? There are 30 PEAR packages in the Database category! I assume people mean MDB2, because it's the most mature and performs best. Another candidate might be rewriting the Drupal database .inc's to use PDO.
I also wonder how much of the objection to some of these DB abstraction layers is a result of the general leery attitude of the Drupal devs towards object oriented code and the dreaded "class" keyword. As PHP5 becomes more and more prevalent, this might be an anachronism and reduce Drupal's ability to compete with other CMS.
I like adodb too, but I dont
I like adodb too, but I dont like the idea to get the core version of drupal about 2mb bigger for this. I really like the small footprint drupal has actually compared to other systems.
Just my 2 cent
Is time to review this idea?
In case of Drupal 6.x, we introduced Schema API (http://api.drupal.org/api/group/schemaapi/6)
In case of Drupal 7.x, we may introduce active record and ORM (http://groups.drupal.org/node/8001)
Therefore our code size is keeping on enlarge and complicate...
On the other hand, all of these have be done with ADOdb for few years ago, e.g.
Data Dictionary Library (http://phplens.com/lens/adodb/docs-datadict.htm)
Active Record (http://phplens.com/lens/adodb/docs-active-record.htm), etc
For sure that, ADOdb also come with a complete multiple database abstraction for basic syntax differences.
Moreover, Moodle, Gallery2, eGroupWare, etc are some successful case study of using ADOdb.
Using external library is not a new idea for Drupal and other OSS, e.g. we are now using JQuery.
So isn't this a good timing for us to use ADOdb for Drupal 7.x, save time from working with database abstraction, and focus on high level usability enhancement?
----------------------------------------
What do you hope from my personal blog??
ADOdb does not necessarily
ADOdb does not necessarily increase db compatibility in the way a lot of commenters think it will because its a db access layer and not a db abstraction layer. Database access layer allows for consistency in the way db connections are created, destroyed, transaction handling, etc.
ADOdb is an excellent database access layer that allows consistent access functions to various backend database. It does incur a performance penalty that can be very significant. Using an accelerator helps a lot. As pointed out in previous comments, it is a fairly heavy weight library and can incur a higher overhead than PearDB.
The other thing is that ADOdb does not address the bigger db compatibility issue of the actual SQL calls. This is what a database abstraction layer does and using a database abstraction layer involves compromises between performance and portability. This is a bit more complicated and can involve significant overhead where complex SQL commands are involved.
Even in applications where I wrote database abstraction layers because of database portability needs there would be areas where I would issue database specific SQL, instead of having the abstraction layer build it, for performance reasons.
ADOdb is a good solution for some situations, but it is not a magic bullet that will solve database portability issues on its own.
All those database backends that it unlocks would still need SQL calls that work with them. A simple example of the variances in the way databases handle SQL would be to look at the way they handle string concatenation. Oracle and Informix uses ||, SQL Server use +, MySQL concat(exp1, exp2...).
Believe me, I would much rather run Drupal with Oracle or SQL Server as the backend DB and never have to work with MySQL again, but ADOdb is not going to provide what a lot of people imagine it would.
Oops, I was thinking about PDO
The performance stuff should apply to ADOdb. However if database specific features and functions are being used in the calls, then portability is sacrificed, i.e. it will improve portability but it does not mean all SQL calls issued by the application will be portable.
The data access layer vs abstraction layer stuff should apply to PDO, which wasn't mentioned but does not incur a significant performance impact, i.e. using PDO is a good thing in my opinion but does not address the SQL call portability issue.
I guess I should shut up and get some sleep.
Sorry!
ADOdb also support PDO backend
The key point is using ADOdb to prepare all of the required functionality, so we can write code as portable with utilize those abstraction. Writing portable query is the duty of developers, but not database access layer nor database abstraction layer ;)
Moreover, ADOdb v5 also come with PDO backend (http://phplens.com/adodb/code.initialization.html#pdo). Their parallel development between legacy and PDO driver can also act as a effective counter prove of my comment about PDO's duty (http://groups.drupal.org/node/8855#pdo_does_doesnt).
As like as my opinion for ADOdb, PDO is also NOT a magic bullet that will solve database portability issues, too ;-(
----------------------------------------
What do you hope from my personal blog??
And that's why Moodle come with XMLDB
Just take Moodle 1.7+ XMLDB as example, they also do some wrapper function on top of ADOdb (http://groups.drupal.org/node/8907#drupal-7.x). Quota from their introduction (http://docs.moodle.org/en/Development:XMLDB_introduction):
I think the usefulness of ADOdb + Drupal is because we don't have enough technical developer for multiple database supporting. E.g. the concat() problem is already addressed by ADOdb with popper abstraction, and so on (http://phplens.com/lens/adodb/tips_portable_sql.htm). If we ship with ADOdb, at least we will not need to asking these as "new features": they are already included :)
I don't seems ADOdb as magic bullet. But at least, that is no point to reroll similar development footprint, if someone have already get most of that done since few years ago, with enough support and still active developing.
----------------------------------------
What do you hope from my personal blog??
Using ADOdb in D6
But not the way you think ... we're using it as a layer for connecting to SQL Server from Drupal Modules. We had been playing with the compiled extension, but support for that has kinda dropped off. That said, I can say that opcode cache definitely helps a lot.
I have used ADOdb on many projects.
I can't comment on the pros and cons of the abstraction vs access layer issues with ADOdb but I can give some professional accounts of using the tool. On at least one project (keep in mind this was working for an agency, and technical requirements and technology standards are usually not used in an agency environment). I was working on a fast burn project for a client's event that required I work with three 3rd party vendor teams.
I chose to use ADOdb as the abstraction layer for the project and as the nature of agile projects (and agile business practices) the underlining database changed mid stream three times during the project development cycle. First we started out on IIS4.0/php4/MSSql 2000, then half way through, because of vendor constraints we had to switch database technologies and use MySQL then three weeks before we had to go live yet again, another vendor required we use Sybase.
Long story short (this is short? ;P) ADOdb provided an abstraction layer the seamlessly migrated to different databases while concurrently developing the system. The queries may be simple by your comparison as we didn't use any stored procedures and the user base was only about 200 to 300 concurrent users. The point is I have used ADOdb on small short-turn and large 1300 concurrent session applications for various projects throughout a six year period.
If the decision is not to use ADOdb perhaps some of the design patterns proofed out in the library could be used to roll our own. I also believe there are "lite" versions of ADOdb the exclude many of the XML and db drivers, etc that provide lightweight distributions. Like this one: http://adodblite.sourceforge.net/index.php