Re: [PHP4BETA] php and MS SQL Server....
| From: | Manuel Lemos | 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
--