Thread: Help with PostgreSQL porting project
Hi all; 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 which conforms to the behavior of the MySQL functions in PHP. This means that a large amount of porting work could be made simple using this porting layer if the application was originally used PHP's native MySQL functions rather than a standard porting layer. The application was originally released under the GPL. I am pleased to announce that I have been able to secure permission from all contributors to be able to re-release this under the LGPL, so that it can be used with non-GPL programs. If there is interest in this project, please let me know. Best Wishes, Chris Travers
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 which > conforms to the behavior of the MySQL functions in PHP. This means that a > large amount of porting work could be made simple using this porting layer > if the application was originally used PHP's native MySQL functions rather > than 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? Just another curious guy from far side of the world, Happy new year :) -- __________ | | | | Enver ALTIN (a.k.a. skyblue) | | Software developer, IT consultant | FRONT | |==========| FrontSITE Bilgi Teknolojisi A.Ş. |_____SITE_| http://www.frontsite.com.tr/
Attachment
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 which >>conforms to the behavior of the MySQL functions in PHP. This means that a >>large amount of porting work could be made simple using this porting layer >>if the application was originally used PHP's native MySQL functions rather >>than 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
Hi, On Fri, 2004-01-02 at 14:20, Arjen van der Meijden wrote: > 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... Please don't get me wrong, I've got an obsession like determining the idea behind any free software project which I'm not really sure if it's a good thing or not. I'm not the only one who thinks there are way too many projects duplicating each other (either completely or partially); wasting human resources and motivation in both short and long term. Just talking about PEAR::DB, you know, it's a generic database abstraction layer which attempts to provide almost the same interface for hopefully all databases supported by PHP; not only for PostgreSQL and MySQL. It's no junk and it's something barely standardized and it's bundled with official PHP distribution. In the end, it's free software. I have noticed no performance bottlenecks in the past and even if there was, I doubt there is a starving need for performance in web applications. And I could be a good salesman so I'd better shut up :) The term "lightweight" means barely nothing to me. Mozilla is FAT, but most of us do use (at least parts of) it. PostgreSQL is not that lightweight, you could use flat-files and POSIX API. For many cases, weight is affordable, and we could possibly help it lose that fat by bug reports. BTW, you have not posted a URL for your work. Could you please do so, if there is any? I would like to take a quick look at your code some time this weekend. Thanks for your patience for reading through the stripped-from-good-ideas proven long text written by me. Happy new year, -- __________ | | | | Enver ALTIN (a.k.a. skyblue) | | Software developer, IT consultant | FRONT | |==========| FrontSITE Bilgi Teknolojisi A.Ş. |_____SITE_| http://www.frontsite.com.tr/
Attachment
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" <acmmailing@vulcanus.its.tudelft.nl> To: "Enver ALTIN" <enver.altin@frontsite.com.tr> Cc: "Chris Travers" <chris@travelamericas.com>; <pgsql-general@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 which > >>conforms to the behavior of the MySQL functions in PHP. This means that a > >>large amount of porting work could be made simple using this porting layer > >>if the application was originally used PHP's native MySQL functions rather > >>than 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 > > > >