NYCPHP Meetup

NYPHP.org

[nycphp-talk] Bizarro Bug -- AHA!!!!!!!

Steve Manes smanes at magpie.com
Wed Apr 2 17:13:49 EDT 2008


Daniel Convissor wrote:
> On Wed, Apr 02, 2008 at 12:14:08PM -0400, Steve Manes wrote:
>> I generally wrap all database calls in API functions specific to the 
>> task being performed, i.e. get_patient_referrals_list(), 
>> put_private_transport_segment(), update_clinic_demographic().  That way 
>> the logging is specific to the task and any specialized processing that 
>> needs to be done to the data can be done in one place.
> 
> That's good.  That still doens't obviate the need to have those functions 
> then call one central function that actually runs the query.

I've never had much need to generalize the database API functions more 
than that if I'm already wrapping them inside dedicated application API 
functions.  I always parameterize the queries so the only potentially 
reusable components would be:

   $result = pg_query_params($db, $sql, $array);

   if (!$result) {
      return array(false, pg_last_error($db));
   }

   $rows = array();

   while ($row = pg_fetch_assoc($result)) {
      $rows[] = $row;
   }

   return array(true, $rows);

But that's limiting as well because some queries are expected to return 
only one row, some return many rows, some result sets are enumerated, 
some are hashes, some need to return the exit code of a stored 
procedure, not the database function.  Also, I like the function to 
return database errors branded with the __FUNCTION__ or __CLASS__ name 
where the error occurred.




More information about the talk mailing list