Re: [PHP4BETA] php and MS SQL Server....

From: Date: Wed, 01 Mar 2000 06:26:09 +0000
Subject: Re: [PHP4BETA] php and MS SQL Server....
References: 1  Groups: php.version4 
Request: Send a blank email to php-version4+get-11240@lists.php.net to get a copy of this message
Hello Michael, On 01-Mar-00 03:27:30, you wrote: >> Commit and Rollback are SQL commands in Microsoft SQL server. I am >> finishing the MSSQL server driver for Metabase, a DBMS independent package >> for access and management of databases in PHP. >Is this like the database abstraction layer? Isn't this being worked on Yes, but much more than just a database access package. It also maintains database schemas (tables, fields, index, sequences) in a DBMS independent way. >already by Stig? It would be a shame for two people to be working on the same >thing independantly If you ask there is much more than two database abastraction layer package being developed for PHP. As for being a shame all the duplicated efforts to achieve the same, I absolutely agree. It seems every one wants to do it in its own way. The reason why I did Metabase is because there was nothing up to the level that I needed. I wanted to develop some package that I doesn't require me to tweak any details when running my database applications under different DBMSs. The packages that I know still require the applications to handle differences like date formats and work arround the unavailablity of certain data types. With Metabase you never need to do that. For instance, date fields always come out in the ISO 9601 format (YYYY-MM-DD HH:MM:SS), the numeric (fixed point) data type is always available (even if has to be emulated with integers fields), etc.. Another goal of Metabase was to get rid of the burden of installing and maintaining database schemas. Usually it is a pain to create database objects: tables, field, indexes, sequences by hand. I designed a XML based format to describe database schema objects in a DBMS independent format. Then I developed a parser class for that format and a manager class to install the database objects from the parsed schema. The manager class is also able to compare two schemas and install the differences. I have been using this extensively to upgrade database schemas without disturbing any data that was added to the database since the it was installed or upgraded for the last time. This saves me a lot of patience figuring the right way to upgrade my database application tables with DBMS specific commands and the risk of screwing it by issuing the wrong command by accident. Evolving my database applications with the necessary database changes has never been this easy (at least for me). In my experience, I can guess that it will take a long time until other PHP database abstraction layers that I know get this much developed. To let you have an idea, it took me more than a year of development and reflection to stabilize Metabase with a solid API (one that you won't need to change with incompatibilities with past versions). What happens is that you need to know a lot about the differences in the DBMS do things so you are able to hide very well those differences behind a solid API. I only released Metabase for beta-testing in November and it was finally released to the public in January. Most of that time I spent writting a thourough user manual and a good tutorial which now have over 140K and 30K of HTML respectively. I'm sure you agree that it wouldn't make much send to drop the development package which does all I need now and has over 6000 lines of code (including some yet to be published drivers). I certainly don't want to compete with Stig or anyone else developing database abstraction layers for PHP. When you develop something and make available for free, usually you want acceptance and expect recognition. An eventual competition for the most accepted free PHP database abstraction layer would be a very ego-sensitive area. If words are not used carefully, you may well be misunderstood as if you were putting down somebody else's effort and that is not my intention. Anyway, the truth is that I see a large overlap not only on Stig's effort to bring up an official database abstraction layer, but also to the whole PEAR project. Think about it how many code repositories like CPAN you know for PHP. I know David Sklar's PX for generic code, Boaz WeberDev for example code, I have developed PHP Classes repository for PHP objects, there are certainly others that I'm sorry to not recall right now. So why another code repository? I have considered suggesting to scale down the PEAR goals to repository of optional PHP modules (C code, not PHP) for PHP 3/4 and instead of duplicating the efforts of the existing PHP code repository sites, sanction them and recommend them to the users that go to php.net . Then I thought to myself, if people wanted it that way, is because there are reasons for it that probably aren't arguable. So it is probably not worthy to discuss it because my intentions as good as I know they are would probably be misunderstood. If people want to rethink it, let them take the initiative. Regards, Manuel Lemos Web Programming Components using PHP Classes. Look at: http://phpclasses.UpperDesign.com/?user=mlemos@acm.org -- E-mail: mlemos@acm.org URL: http://www.mlemos.e-na.net/ PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp --

« previous php.version4 (#11240) next »