Re: Php abstraction layers - Mailing list pgsql-general

On Tue, 2005-30-08 at 21:00 -0700, Chris Travers wrote:
> Antimon wrote:
>
> >Hi,
> >I'm working on a new web project based on php and i decided to use
> >PostgreSQL 8.x as
> >dbms. For triggers, views, stored procedures etc. I was going to write
> >a simple wrapper class and use pg_* functions. But some friends adviced
> >me to use an abstraction layer. I checked PEAR:DB and AdoDB. They look
> >pretty but i don't understand why sould i need one?
> >
> Do yourself a favor and write lightweight wrapper functions.  This means
> that if something needs to be changed (say, a PHP API name change
> happens) you don't have to rewrite a lot of your code.  Additionally, if
> you do have to port someday to Interbase or even (gasp) MySQL, it
> becomes possible thought not always straightforward.
>   *Simple* and light database abstractions are very nice because they
> isolate your framework from the API syntax and after a few years,
> something could change and then you don't have to rewrite a whole lot.
>
I would have to agree with this.

As a network administrator I work with IP and MAC addresses alot,
so I can use the extensive support for them as leverage when
choosing a database for a project. That being said, I have other
people to please and sometimes they get their way and I have to
use MySQL. I do not to use PEAR or CPAN modules because I haven't
had the time to learn their API's and don't know how secure they
are.

As Chris suggests, I write wrapper functions to create and
maintain one or more connections to the database as well as
functions for inserting, updating, deleting and making
different kinds of selections from the database. I have found
it handy to store status, error and data in an array of
associative arrays for each transaction with the database. The
trick to making the code compatible is how and where the error
and status data is stored. The PostgreSQL pg_ functions return
quite different error and status information than the MySQL
functions.

Another trick is to write wrapper functions that take a
"driver" option to determine which "library" to use. Since the
same array format is returned from either "library" the rest of
the code doesn't need to know anything about the database.

One thing to take care with is ; making sure you escape any
filter anything put into a database command to ensure that
you don't create SQL injection vulnerabilities.