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
