Subject: Re: Zend_Db_Table_Select .... bug? - msg#00072

Previous Message by Date: click to view message preview

Re: Zend_Db_Table_Row_Exception: Cannot refresh row as parent is missing

The error you got is because the row cannot be retrieve from the database after being save. Do you set the value of type_id on your row before saving it ?   I would override createRow too with something like public function createRow(array $data = ""> {  $data['type_id'] = 1;  return parent::createRow($data); }     The getWhereQuery just build a condition based on the primary key, if you miss it, then it will not work too. I used to have some issue with datetime as primary key or part of it. Then the call to fetchRow will restrict to your type.       2008/6/3 Avi Block <atblock-Re5JQEeQqe8AvxtiuMwx3w@xxxxxxxxxxxxxxxx>: I'm trying to implement some kind of single-table inheritance...for all my"children" i'm trying to extend Zend_Db_Table and override the _fetch method as follows:public function _fetch($select) {               $select->where(type_id=?', 1);               return parent::_fetch($select);}However when I try to save a row: $row = $table->createRow();.....$row->save();I get the exception: Zend_Db_Table_Row_Exception: Cannot refresh row asparent is missingI tried digging in and I found something which doesn't make sense to me... The _refresh method contains the following code:$where = $this->_getWhereQuery();$row = $this->_getTable()->fetchRow($where);$where gets set to "id = 0"...and it finds a row... The strangest part is that I don't have an item with an id of 0, since istarted from 1.--View this message in context: http://www.nabble.com/Zend_Db_Table_Row_Exception%3A-Cannot-refresh-row-as-parent-is-missing-tp17633272p17633272.html Sent from the Zend DB mailing list archive at Nabble.com.

Next Message by Date: click to view message preview

Re: Zend_Db_Table_Select .... bug?

Hi thereI'd like to clear up any confusion about this and put a little extra detail around the reasoning for Zend_Db_Table_Select working the way it does.Its parent, Zend_Db_Select must have an explicit 'from' (or inner join) set before it can work. Originally, using the 'from' method set both the target table and specific fields, and there was no way to override this - the 'columns' method was not added until after 1.5. So essentially, once you'd set the 'from' table and fields you were stuck with it.This is why the Zend_Db_Table_Select component waits until the very last possible moment before applying the source fields. If it added the table name and fields in the constructor and did nothing else, sure it would work fine. But how would you go about creating a read-only table instance with only two or three columns? If you call 'from' more than once on a select object, it adds the second as an inner join and can mess up your query. Allowing the developer to supply the 'from' allowed a more flexible approach (relating more to the fields rather than the table name, obviously).Since then a couple of similar bugs relating to this have cropped up:- Where 'join' is called before explicitly setting the 'from' table, it creates an incorrect query (i.e. the 'join' becomes an inner join). This can be fixed by refactoring the select object and allowing them to be stored separately internally. So 'from' won't quite be the same process for both Zend_Db_Select and Zend_Db_Table_Select.I will be working with Jurrien to establish the best way to tackle this (as one of his components also depends on this) - we may end up performing a 'reset' columns internally on the Zend_Db_Select object and bypassing the problem altogether.Look out for an update soon!i got the same issue and think the same thing : __toString() should NOT modify the instance. As for the documentation, we definitely not have the same source : http://framework.zend.com/manual/en/zend.db.table.html   Example 10.97. Using a lookup table to refine the results of fetchAll()<?php$table = new Bugs();$select = $table->select();$select->where('bug_status = ?', 'NEW')       ->join('accounts', 'accounts.account_name = bugs.reported_by')        ->where('accounts.account_name = ?', 'Bob');$rows = $table->fetchAll($select);   And i can't see the from statment, same apply to example 10.98.     The fact, is that the select will at least use the table it comes from, why not return it with the from clause already set ?         2008/7/10 Pepa <Jo.Pi-9Vj9tDbzfuSlVyrhU4qvOw@xxxxxxxxxxxxxxxx>: Michael Stoiber wrote:>> if you echo $select you call $select->__toString().> $select is an object. normally it's not possible to echo an object.>> if you start a query without from(), $select takes the standard-table > when rendering the statement (with __toString).>Maybe I just didn't expressed myself well. Sure it just calls __toString().The thing is, that calling __toString changed the object, because then it assigned the standard-table. And it shouldn't in my opinion. Usually__toString() shouldn't change the object. I'd expect that either thestandard-table is assigned from the beginning or it doesn't auto-assign to the object after calling the __toString(). > I see. Thanks For help.>> However, just an idea - when it is already instantiated> Zend_Db_Table_Select> by some particular table, shouldn't  the ->from() be already set? Or at > least,> shouldn't it behave in more consistent way and do not change the output> after calling __toString() ?>>> Michael Stoiber wrote:>>> to join something you need to use the select()->from()- Method first to >> tell the join method the bsic table zo join with.>> see dokumentation for more details.>>>> mike>>>>> Hi,>>>>>>   I'm using the newest ZF and I have an following problem: >>>   I have three tables cat (categories, id column as primary),>>> prod(products,>>> id column as primary), catprod (intersection table, cat_id and prod_id>>> columns). Now I want to build Select in the Prod table class that will >>> fetch>>> only those products which belong to some particular category. It means>>> products fulfilling this condition: prod.id = catprod.prod_id AND >>> catprod.cat_id = [category_id].>>>  Now we are in Prod class:>>>>>>   function getProds()>>>   {>>>       $select = $this->select();>>>       //echo "<p>"; echo $select; echo "</p>"; >>>       $select->join("catprod", "catprod.prod_id = prod.id", array());>>>       echo "<p>"; echo $select; echo "</p>"; >>>>>>       //omitting the part cat_id = [], needless for the bug>>>   }>>>>>> And what is the result?>>>>>> SELECT `prod`.* FROM `catprod` INNER JOIN `prod` >>>>>> Hey, the condition "catprod.prod_id = prod.id" is missing! But let's say>>> I>>> just did something wrong and uncomment the //echo ... line and have a >>> look>>> at the result:>>>>>> SELECT `prod`.* FROM `prod`>>>>>> SELECT `prod`.* FROM `prod` INNER JOIN `catprod` ON catprod.prod_id =>>> prod.id >>>>>> It's not hard to guess, that instead of echoing it, calling>>> $select->__toString(); does the same job, and actually I am using it to>>> patch this behaviour. >>>>>> The question is: Am I doing something wrong or is it a bug?>>>>>>>>>>>>--View this message in context: http://www.nabble.com/Zend_Db_Table_Select-....-bug--tp18381496p18382185.html Sent from the Zend DB mailing list archive at Nabble.com. --Simon Mundy | Director | PEPTOLAB""" " "" """""" "" "" """"""" " "" """"" " """"" "  """""" "" "202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000Voice +61 (0) 3 9654 4324 | Mobile 0438 046 061 | Fax +61 (0) 3 9654 4124http://www.peptolab.com

Previous Message by Thread: click to view message preview

Re: Zend_Db_Table_Select .... bug?

Michael Stoiber wrote: > > if you echo $select you call $select->__toString(). > $select is an object. normally it's not possible to echo an object. > > if you start a query without from(), $select takes the standard-table > when rendering the statement (with __toString). > Maybe I just didn't expressed myself well. Sure it just calls __toString(). The thing is, that calling __toString changed the object, because then it assigned the standard-table. And it shouldn't in my opinion. Usually __toString() shouldn't change the object. I'd expect that either the standard-table is assigned from the beginning or it doesn't auto-assign to the object after calling the __toString(). > I see. Thanks For help. > > However, just an idea - when it is already instantiated > Zend_Db_Table_Select > by some particular table, shouldn't the ->from() be already set? Or at > least, > shouldn't it behave in more consistent way and do not change the output > after calling __toString() ? > > > Michael Stoiber wrote: > >> to join something you need to use the select()->from()- Method first to >> tell the join method the bsic table zo join with. >> see dokumentation for more details. >> >> mike >> >>> Hi, >>> >>> I'm using the newest ZF and I have an following problem: >>> I have three tables cat (categories, id column as primary), >>> prod(products, >>> id column as primary), catprod (intersection table, cat_id and prod_id >>> columns). Now I want to build Select in the Prod table class that will >>> fetch >>> only those products which belong to some particular category. It means >>> products fulfilling this condition: prod.id = catprod.prod_id AND >>> catprod.cat_id = [category_id]. >>> Now we are in Prod class: >>> >>> function getProds() >>> { >>> $select = $this->select(); >>> //echo "<p>"; echo $select; echo "</p>"; >>> $select->join("catprod", "catprod.prod_id = prod.id", array()); >>> echo "<p>"; echo $select; echo "</p>"; >>> >>> //omitting the part cat_id = [], needless for the bug >>> } >>> >>> And what is the result? >>> >>> SELECT `prod`.* FROM `catprod` INNER JOIN `prod` >>> >>> Hey, the condition "catprod.prod_id = prod.id" is missing! But let's say >>> I >>> just did something wrong and uncomment the //echo ... line and have a >>> look >>> at the result: >>> >>> SELECT `prod`.* FROM `prod` >>> >>> SELECT `prod`.* FROM `prod` INNER JOIN `catprod` ON catprod.prod_id = >>> prod.id >>> >>> It's not hard to guess, that instead of echoing it, calling >>> $select->__toString(); does the same job, and actually I am using it to >>> patch this behaviour. >>> >>> The question is: Am I doing something wrong or is it a bug? >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/Zend_Db_Table_Select-....-bug--tp18381496p18382185.html Sent from the Zend DB mailing list archive at Nabble.com.

Next Message by Thread: click to view message preview

Re: Zend_Db_Table_Select .... bug?

Hi thereI'd like to clear up any confusion about this and put a little extra detail around the reasoning for Zend_Db_Table_Select working the way it does.Its parent, Zend_Db_Select must have an explicit 'from' (or inner join) set before it can work. Originally, using the 'from' method set both the target table and specific fields, and there was no way to override this - the 'columns' method was not added until after 1.5. So essentially, once you'd set the 'from' table and fields you were stuck with it.This is why the Zend_Db_Table_Select component waits until the very last possible moment before applying the source fields. If it added the table name and fields in the constructor and did nothing else, sure it would work fine. But how would you go about creating a read-only table instance with only two or three columns? If you call 'from' more than once on a select object, it adds the second as an inner join and can mess up your query. Allowing the developer to supply the 'from' allowed a more flexible approach (relating more to the fields rather than the table name, obviously).Since then a couple of similar bugs relating to this have cropped up:- Where 'join' is called before explicitly setting the 'from' table, it creates an incorrect query (i.e. the 'join' becomes an inner join). This can be fixed by refactoring the select object and allowing them to be stored separately internally. So 'from' won't quite be the same process for both Zend_Db_Select and Zend_Db_Table_Select.I will be working with Jurrien to establish the best way to tackle this (as one of his components also depends on this) - we may end up performing a 'reset' columns internally on the Zend_Db_Select object and bypassing the problem altogether.Look out for an update soon!i got the same issue and think the same thing : __toString() should NOT modify the instance. As for the documentation, we definitely not have the same source : http://framework.zend.com/manual/en/zend.db.table.html   Example 10.97. Using a lookup table to refine the results of fetchAll()<?php$table = new Bugs();$select = $table->select();$select->where('bug_status = ?', 'NEW')       ->join('accounts', 'accounts.account_name = bugs.reported_by')        ->where('accounts.account_name = ?', 'Bob');$rows = $table->fetchAll($select);   And i can't see the from statment, same apply to example 10.98.     The fact, is that the select will at least use the table it comes from, why not return it with the from clause already set ?         2008/7/10 Pepa <Jo.Pi-9Vj9tDbzfuSlVyrhU4qvOw@xxxxxxxxxxxxxxxx>: Michael Stoiber wrote:>> if you echo $select you call $select->__toString().> $select is an object. normally it's not possible to echo an object.>> if you start a query without from(), $select takes the standard-table > when rendering the statement (with __toString).>Maybe I just didn't expressed myself well. Sure it just calls __toString().The thing is, that calling __toString changed the object, because then it assigned the standard-table. And it shouldn't in my opinion. Usually__toString() shouldn't change the object. I'd expect that either thestandard-table is assigned from the beginning or it doesn't auto-assign to the object after calling the __toString(). > I see. Thanks For help.>> However, just an idea - when it is already instantiated> Zend_Db_Table_Select> by some particular table, shouldn't  the ->from() be already set? Or at > least,> shouldn't it behave in more consistent way and do not change the output> after calling __toString() ?>>> Michael Stoiber wrote:>>> to join something you need to use the select()->from()- Method first to >> tell the join method the bsic table zo join with.>> see dokumentation for more details.>>>> mike>>>>> Hi,>>>>>>   I'm using the newest ZF and I have an following problem: >>>   I have three tables cat (categories, id column as primary),>>> prod(products,>>> id column as primary), catprod (intersection table, cat_id and prod_id>>> columns). Now I want to build Select in the Prod table class that will >>> fetch>>> only those products which belong to some particular category. It means>>> products fulfilling this condition: prod.id = catprod.prod_id AND >>> catprod.cat_id = [category_id].>>>  Now we are in Prod class:>>>>>>   function getProds()>>>   {>>>       $select = $this->select();>>>       //echo "<p>"; echo $select; echo "</p>"; >>>       $select->join("catprod", "catprod.prod_id = prod.id", array());>>>       echo "<p>"; echo $select; echo "</p>"; >>>>>>       //omitting the part cat_id = [], needless for the bug>>>   }>>>>>> And what is the result?>>>>>> SELECT `prod`.* FROM `catprod` INNER JOIN `prod` >>>>>> Hey, the condition "catprod.prod_id = prod.id" is missing! But let's say>>> I>>> just did something wrong and uncomment the //echo ... line and have a >>> look>>> at the result:>>>>>> SELECT `prod`.* FROM `prod`>>>>>> SELECT `prod`.* FROM `prod` INNER JOIN `catprod` ON catprod.prod_id =>>> prod.id >>>>>> It's not hard to guess, that instead of echoing it, calling>>> $select->__toString(); does the same job, and actually I am using it to>>> patch this behaviour. >>>>>> The question is: Am I doing something wrong or is it a bug?>>>>>>>>>>>>--View this message in context: http://www.nabble.com/Zend_Db_Table_Select-....-bug--tp18381496p18382185.html Sent from the Zend DB mailing list archive at Nabble.com. --Simon Mundy | Director | PEPTOLAB""" " "" """""" "" "" """"""" " "" """"" " """"" "  """""" "" "202/258 Flinders Lane | Melbourne | Victoria | Australia | 3000Voice +61 (0) 3 9654 4324 | Mobile 0438 046 061 | Fax +61 (0) 3 9654 4124http://www.peptolab.com