Re: RE : [PEAR] DataObject: upgrade from 1.2 to 1.3 problems

Hi Alan, The INI setting sounds nice as I won't have to change my code (yet). Still though IMHO the fact that you have to clone an object to be able the execute a method twice is *very* counter intuitive and inconvinient and will require more code, while the nice thing about DataObjects has always been that it's easy to use and requires little effort. With dataobjects you only need a couple of lines of code to do a lot of cool things. Sure it's a bit slower than some other solutions, but DO users are willing to pay that "price" for the added value they get. Just my 2 cents, Jeroen Alan Knowles wrote:

Actually, I've been thinking this one through, I would like the long term solution to be that finding twice on the same object is not permitted - as it has a number of benifits: - smaller objects size (print_r/object storage..) - reduces 'unexpected behaviour' however, as a transition measure, I think adding (yet another) ini option: ; prior to version 1.3, you could use ->find() twice on the same object ; in newer versions, you should either clone the object before finding, ; or use a new instance. ; This is defaulted to OFF (eg. 0), however, if your code relies on this ; 'feature' you should turn it on. - It will be removed when DataObject ; goes to version 2 (one day) ; DO NOT USE THIS IN NEW CODE... depreciated_allow_multifind = 1 is the simplest way to handle this.. A) it will default to OFF, so new programs will not have the same error. B) old applications can be made to work in the same way, with a very small change. == the errors below are because 1.4 currently clears the select add, so it doesnt fetch those variables on the second find. - hence they are not found. Regards Alan Jeroen Houben wrote:

Hi Alan,

This was part of the plan to reduce the size of print_r, the data size (and theoretically improve performance..) things like select/condition/limit/order etc. are stored in an array which is cleared after a query. I already added this to ->get(), "You should avoid calling get on the same object instance twice, as this will result in unexpected results." The Changelog should have flagged this - "You may not run a find on an object that has already had this run on it.." But I forgot to add it to the changelog :( Previously I did the clearing of the query on fetch(), but this adds an extra call to the fetch method, (and slows things down a little..) prehaps just going back to this, and doing a simple variable check is the best compramise..

You mean you will go back to the old behaviour in the next release? That would be nice. Not being able to run find() twice on the same object seems very counter intuitive to me. Any thoughts on the problem I'm having with selectAdd? For full description please see previous post (near the bottom) http://marc.theaimsgroup.com/?l=pear-general&m=106968008924496&w=2 Thanks! Jeroen

Regards Alan Jeroen Houben wrote:

Why though? And isn't this a BC break? My second error definately sounds like a BC break, although it might just be a result of the first error. LIMBOURG Arnaud wrote:

Hi, I had the same message, you can avoid it by doing $do_1 = new DataObject; $do_2 = $do_1->__clone(); $do_1->find(); About the second error, i don't know. Arnaud.

thw Var_Dump() call gives me a message: You cannot do two queries on the same object (copy it before finding) Also I get notices: Notice: Undefined property: start_stamp in xxx on line 99 Notice: Undefined property: end_stamp in xxx on line 100 This must have something to do with the selectAdd not working as it worked before (?) Help much appreciated,