[support] Drupal 7 Database API

[Warren Vail]

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 at drupal.org [mailto:support-bounces at drupal.org] On
Behalf Of Tim Gustafson
Sent: Tuesday, January 10, 2012 2:54 PM
To: support at 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 at soe.ucsc.edu
Baskin School of Engineering
831-459-5354
UC Santa Cruz                                         Baskin Engineering
317B
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-

-- 
[ Drupal support list | http://lists.drupal.org/ ]