[support] db_select()->condition()

[Metzler, David]

The question about check plain vs. non-check plain is really about the data and how it is used. Check plain is generally not used in the condition db-comparison layer because that's not the point where you're trying to prevent cross site scripting vulnerabilities.  Rather that happens at presentation. 

In general drupal's strategy has been to sanitize data prior to presentation, not prior to storage.   So until you're passing stuff to the presentation layer, you wouldn't normally run stuff through check_plain.  Check_plain does not provide SQL Injection protection, and since the data is stored in the raw, you don't want to run checkplain on something before the comparison of that value in the condition.  The SQL injection protection is all handled internally within DBTNG and db_query now, and check_plain never performed this protection anyway. 

The idea behind DBTNG is to get away from token substitution and into an object-relational mapping (ORM) style of coding.   So this really is the new drupal way.  

http://drupal.org/node/1067802#comment-4169252 is one of the places where you'll find information posted by crell on this topic. 

Here's another interesting stack exchange article that lists some reasons to use db_select: 

http://drupal.stackexchange.com/questions/1200/given-that-db-select-is-much-slower-than-db-query-why-would-i-want-to-use-it

Hope that helps, 

Dave

-----Original Message-----
From: support-bounces at drupal.org [mailto:support-bounces at drupal.org] On Behalf Of Earnie Boyd
Sent: Friday, May 25, 2012 5:05 AM
To: support at drupal.org
Subject: Re: [support] db_select()->condition()

On Thu, May 24, 2012 at 4:56 PM, Metzler, David wrote:
> Two things:
>
> 1.  Don't use db_select just because you're converting a module.  You
> are adding overhead that doesn't need to be there. Event the authors of
> DBTNG agree with this statement.  Stick to db_query unless you need to
> generate SQL dynamically.
>

I understand that db_select builds a string that is eventually passed
to MySQL but what overhead is added?  Can you point to threads of
discussion?

> 2. Change the variable prior to binding it.  Don't do token replacement
> at all.  The idea is that the second parameter of the condition method
> should be that variable that contains the array, not a token replacement
> thing so if you're trying to make a wild card like, just concat like
> this:
>
> db_select('mytable', 'mt')
>  ->fields('mt', array('myvar'))
>  ->condition('mystring', '%' . $somrvariable . '%', LIKE)
>  ->execute();

Ok, thanks.  It just doesn't seem Drupalish, I would have expected an
optional 4th argument to provide token substitution.  Shouldn't it be
check_plain($somevariable) then?  Probably depends on how
$somevariable gets a value.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd
-- 
[ Drupal support list | http://lists.drupal.org/ ]