Agreed.

I already told Zend (ralph probably) that a Zend_Db_Table_Select should be given it's own table in the from clause, just after creating it.
It's not logic to have a Zend_Db_Table_Select entirely empty at creation, it should at least contains its own table as its first from clause.

See :

// that's not logic
$table->fetchall($table->select()->from($table, array('my', 'cols')));

// that seems more logic
$table->fetchall($table->select()->columns(array('my', 'cols')));

Turns out just adding the from in the setTable doesn't act as expected.

$select = $tbl->select()->columns('id'); would still include an all columns in the select.

'select `table`.* , `table`.`id` from `table`'

Attached is a patch I used to fix the bug for me.

short version:
Added a different version of the columns method for the class that includes the 'from' on demand.
If a column not from the primary table is requested, it will throw an error.
Seemed logical since the assemble for Zend_Db_Table_Select would throw for any columns not in the primary table.

This issue is already known as ZF-3239. It's a tricky one and hard solve without BC issues. A real patch probably won't be available until ZF 2.0, where we can break the BC a bit. Although I would love to be proven wrong in this case

Since 1.9 there has been a feature in place that allowed select() to be called on a table with that will load the from part into the object.

Please see here, and the api doc here

I think it might fix this problem.

-ralph

Was fixed as of 1.9. Marking issue closed.