[support] db_select()->condition()

[Jamie Holly]

As far as the overhead of dynamic queries, see this issue starting at 
comment #8:

http://drupal.org/node/835068#comment-3125136

You don't have to do a check_plain on your field. PDO knows what type of 
field is being populated and automatically prepares them as needed. This 
all happens up in the driver and invoked by PDO::Prepare(). In DBTING, 
the prepare is called when you do the ->execute(), so you don't have to 
worry about calling it.

Jamie Holly
http://www.intoxination.net
http://www.hollyit.net


On 5/25/2012 8:04 AM, Earnie Boyd wrote:
> 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.
>