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)? That's 2 each for:
ALL, DISTINCTROW, HIGH_PRIORITY, STRAIGHT_JOIN, SQL_SMALL_RESULT,
SQL_BIG_RESULT, SQL_BUFFER_RESULT, SQL_CACHE, SQL_NO_CACHE,
SQL_CALC_FOUND_ROWS
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.
-Hector
Bill Karwin wrote:
Hector Virgen wrote:
I want to be able to produce the following SELECT statement:
SELECT *SQL_CALC_FOUND_ROWS* * FROM table LIMIT 10;
I've considered subclassing Zend_Db_Select to handle this, but I would
have to redefine __toString() to support this.
SQL_CALC_FOUND_ROWS is a MySQL proprietary thing, and adding it to
Zend_Db_Select would break on other RDBMS brands. In general,
Zend_Db_Select supports only ANSI SQL syntax (except for the limit()
functionality).
Take a closer look at Zend_Db_Select. It has been refactored in recent
months to make it easier to do what you're describing in a subclass. You
shouldn't have to change __toString(), just do this:
- add a key to the $_partsInit array for the option you want; it probably
belongs before DISTINCT
- add functions sqlCalcFoundRows() and _renderSqlCalcFoundRows()
See functions distinct() and _renderDistinct() as examples.
Regards,
Bill Karwin
