Re: Adding SELECT options to Zend_Db_Select

I've tried implementing your solution but I'm having trouble with the late static binding of the array Zend_Db_Select::$_partsInit. I don't think there's a way around this issue without upgrading to PHP 5.3, but I may be wrong. This is why I mentioned I would have to redefine __toString() -- I'd have to do a substr_replace() on parent::__toString() to insert SQL_CALC_FOUND_ROWS into the SELECT query.

And, yes, I actually use the extra options in my select queries. I prefer SQL_CALC_FOUND_ROWS when I'm building complex queries that use subqueries and "having" clauses, which would be a waste of cpu cycles to repeat the same complex query twice just for the total count. MySQL will recognize that the query is different and repeat all of the joins and lookups all over again.

And there are a lot of benefits from properly using SQL_CACHE / SQL_NO_CACHE / HIGH_PRIORITY.

To be denied access to these options just because database X doesn't support it doesn't quite seem right to me.

-Hector

Bill Karwin wrote:

Hector Virgen wrote:
  

Thanks, Bill. So in order to fully support MySQL I suppose I'd have to 
write a total of 20 new methods that all basically do the same thing 
(they each add an option after the "SELECT" portion of the statement)? 

    

Right, but I'd be shocked and amazed if you actually use more than two of
those SELECT options in your entire life.


Hector Virgen wrote:
  

Also, subclassing Zend_Select introduces other problems. For example, 
when I use $table->select(), it internally creates an instance of 
Zend_Db_Table_Select, which extends Zend_Db_Select, therefore not using 
my subclass My_Db_Select.

    

Yep, that's a problem.  You may not be able to use the extra SQL options in
your Zend_Db_Select_Mysql class when using the $table->select() method.  But
standard use of $table->select(), without the extra options, will still work
of course.

You could copy Zend_Db_Table_Select and create a new class that extends your
enhanced Select class.  That's up to you, if you think you really need those
MySQL options when using the Table interface.  If it were me, I'd exercise
the better part of valor, forget about SQL_CALC_FOUND_ROWS, and just use a
"SELECT COUNT(*)" query instead.

Regards,
Bill Karwin