Actually, I already had a few thousand lines of code done (using PHP's MySQL
functions) and I needed an abstraction layer to conform to my existing code.
In this case, if an application has been written with PHP's MySQL functions,
porting it to this layer would be simple and straightforward, with a minimum
of rewriting code (aside from, perhaps checking a few queries). Most of it
could be handled with search/replace facilities.
Even with a standard abstraction layer like PEAR or ADODB, the query syntax
is not identical between database managers. Although this is not nearly
perfect, I have attempted abstract over many of these differences (LIMIT
clauses, timestamp formats, etc.) The abstraction is not perfect but it
helps. A few additional functions could be written to better abstract some
of these things.
Basically these files contain a set of light-weight wrappers to facilitate
porting frim MySQL to PostgreSQL of PHP applications.
Basically, incompatibility comes from three things:
1: Incompatible data representation (aside from timestamps not handled by
most abstraction layers, including this one). However, some of these could
be better handled (such as BOOLs).
2: Incompatible function behavior (normally handled by any abstraction
layer)
For example PostgreSQL's return sets are not forward only, while MySQL's
are.
3: Query differences. For example, if I write:
SELECT * FROM customers ORDER BY last_name LIMIT 30 OFFSET 30
This will run on MySQL, but not PostgreSQL. I handled the difference in my
project by adding a function to generate limit clauses for given offsets and
limits. For RDBMS's that don't support offsets (MSSQL, Firebird), this
would be a bit more complex, but it could be done.
In other words, this is a simple API wrapper to make the db's behave the
same. It is NOT OO.
Best Wishes,
Chris Travers
----- Original Message -----
From: "Arjen van der Meijden" <ac********@vulcanus.its.tudelft.nl>
To: "Enver ALTIN" <en*********@frontsite.com.tr>
Cc: "Chris Travers" <ch***@travelamericas.com>;
<pg***********@postgresql.org>
Sent: Friday, January 02, 2004 7:20 PM
Subject: Re: [GENERAL] Help with PostgreSQL porting project
Enver ALTIN wrote:
Hi,
On Fri, 2004-01-02 at 13:38, Chris Travers wrote:
A few years ago, I set about porting a PHP application from MySQL to
PostgreSQL, after realizing that MySQL wasn't going to be able to handle
it.In order to do this, I built a light, fast database abstraction layer
whichconforms to the behavior of the MySQL functions in PHP. This means that
alarge amount of porting work could be made simple using this porting
layerif the application was originally used PHP's native MySQL functions
ratherthan a standard porting layer. The application was originally released
under the GPL.
I guess it might bother you when people ask this but, what made you do
the hardwork while it's already been done by several other projects like
PHP ADODB and PEAR?
Are those two LIGHT weight?
Afaik, PEAR (DB) affects the performance of your OO-php-app quite bad,
but I haven't really tested it very often myself, just seen tests by
others? And I'm not talking "quite bad, because php is not very fast in OO", I'm
talking "quite bad, compared to other (custom built, light weight,
simple) OO abstraction layers".
Maybe that has changed since then? But I have, for that reason, never
really started using PEAR...
Best regards,
Arjen
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to
ma*******@postgresql.org 
