Ah yes we ol' dinosaurs are still worth our salt! Thanks for that Warren!
Tony
tony mac is building web sites.
-----Original Message----- From: "Warren Vail" warren@vailtech.net Sender: support-bounces@drupal.org Date: Tue, 10 Jan 2012 15:54:07 To: support@drupal.org Reply-To: support@drupal.org Subject: Re: [support] Drupal 7 Database API
Had to Smile - with 45 years programming, I think I see a possible goal of the oo design;
By treating every data element as a separate object the API can scan better for SQL injection and other hacks, while improving the ability to be database engine independent. Think about, sometime in the future, supporting a Chinese language version of SQL, as terrifying as that might appear on the surface, the "better" version OO API might just be able to interface to it (might being the operative word here). :-)
If it ain't broke,,,,,, some day it will be.
Warren Vail
-----Original Message----- From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Tim Gustafson Sent: Tuesday, January 10, 2012 2:54 PM To: support@drupal.org Subject: [support] Drupal 7 Database API
Hi,
Before I ask my question, I'd like to throw out a disclaimer here: I thought pretty long and hard about sending this e-mail because I know that it is going to rake up the inevitable "procedural versus OO" war, but I feel this is worth asking. I've been programming for more than 20 years, and I know that "procedural vs OO" is not something that anyone will ever win.
That said...
I'm in the process of converting about three dozen modules I've written for my organization from Drupal 6 to Drupal 7.
I get that when you go from one API version to the next in a system like Drupal that there are always changes. Those changes are usually needed to make some new feature available or to make something "better" in some sense. I get that.
What I don't get is: why did Drupal decide to re-invent SQL as an object-oriented interface?
I'm finding is that a simple on-line SQL query in a Drupal 6 module, for example:
$foo = db_query( "select * from {foo} where bar >= date_sub(now(), interval 1 month) order by bar desc limit %d", variable_get("baz", 10) );
has changed to:
$foo = db_select("foo", "f") ->fields("f") ->condition("bar", "date_sub(now(), interval 1 month)", ">=") ->orderBy("bar", "desc") ->range(0, variable_get("baz", 10));
I'm having a hard time understanding how taking a well-defined, extremely popular, gold-standard language (SQL) and changing it into this OO code makes anything better. The code is not any more readable than the straight SQL statement, in my opinion. I can only imagine how it looks when I get into doing complex joins and unions and such. And I can't debug it by copying-and-pasting it into a mySQL client window. I'm guessing that from the standpoint of raw code efficiency, it has got to be slower than the single-line-query approach because you're iterating through PHP's internal function calling routines five times now instead of just once and each one of those calls has some overhead related to decoding the variables it receives.
What does this switch from regular SQL statements to OO get us?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - Tim Gustafson tjg@soe.ucsc.edu Baskin School of Engineering 831-459-5354 UC Santa Cruz Baskin Engineering 317B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -