Re: DB_Result fetchRow() && fetchInto()

From: Date: Wed, 11 Jun 2003 19:37:58 +0000
Subject: Re: DB_Result fetchRow() && fetchInto()
References: 1 2 3  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-17326@lists.php.net to get a copy of this message
----- Original Message ----- From: "Roman Neuhauser" <neuhauser@bellavista.cz> > # cox@idecnet.com / 2003-06-11 11:14:24 +0200: > > From: "Roman Neuhauser" <neuhauser@bellavista.cz> > > > these two methods are quite long, and have basically identical bodies. > > > why doesn't one just call the other? > > > > Performance. > > Have you volunteered to keep the redundant code in sync? If you did, > you failed. The answer should've been: bugs and more maintenance > work. Diff their bodies: The code was synced. Just a minor issue (a result not free'ed) when: 1) You use autofree 2) Call limitQuery() 3) Retrieve with fetchInto() 4) The backend doesn't implement emulated row limit support > With DB_FETCHMODE_OBJECT, one does $ret =& new $class, the other > $ret = new $class => different behavior. Of course you haven't tested that. You'll get a marvellouse NULL instead of the object if you change it. Just try: <?php function a(&$a) { // remove '&' to get the obj right $a = &new StdClass; } a($obj); var_dump($obj); ?> Ouput is "NULL" I don't know if that's the expected behaviour in php, but in that case the change would break DB_FETCHMODE_OBJECT. > Also, one of them doesn't free the result in certain circumstances. Yes, I missed that 2 lines while coding the limit feature of PEAR DB. Fixed now, thanks. > Performance is nothing when compared to hard to maintain software, Performance is one of the problems of PEAR DB and should be fixed. I'll try to get on it after cleaning the bug db and other bunch of pending things. An advance at: http://marc.theaimsgroup.com/?l=pear-dev&m=100793507904834&w=2 > If you like buggy but fast software, that's your call. I prefer > software that works correctly. Do I need to answer that? Tomas V.V.Cox

« previous php.pear.dev (#17326) next »