Re: [PHP4BETA] DB in PEAR and other questions
| From: | Manuel Lemos | Date: | Sat, 06 May 2000 14:03:06 +0000 |
| Subject: | Re: [PHP4BETA] DB in PEAR and other questions | ||
| References: | 1 | Groups: | php.version4 |
| Request: | Send a blank email to php-version4+get-14592@lists.php.net to get a copy of this message | ||
Hello Andrew,
On 06-May-00 06:31:46, you wrote:
>> >3) Also, has anyone wrapped the mysql function mysql_insert_id() in the
>> >mysql.php?
>>
>> The problem is that not all DBMS support auto incremented fields. If you
>> want to write portable database applications, you'd better not use tables
>> with auto incremented fields. If you don't want to write portable
>> applications, maybe it is better that you use mysql functions directly.
>It seems to me that because the of the way that the classes are set up in
>PEAR now, that is, DB_mysql extends DB_common, that it is logical to set
>this up. For example, because transactions are not possible under MySQL,
>calling the commit() and rollback() methods will result in an error
>DB_ERROR_NOT_CAPABLE.
That's not the point. There is no way to achive the same goal in MySQL
as if it had full transaction support.
>What should probably be happening is that for databases that are not able
>to support the function call to get the last inserted id that the function
>should return a DB_ERROR_NOT_CAPABLE like the way that it is handled now.
And then what? If you use a function like that in your database
applications it simply can't run like that with DBMS that don't support it.
>Also, and hopefully I'm not making a obvious oversight here-- what DBMS do
>you know of that doesn't support auto incremented fields?
Several, but if you think just of important DBMS being used a lot in Web
applications like Oracle and PostgreSQL, you see that this is not a trivial
issue.
I studied several database abstraction packages. One common design mistake
that several PHP database abstractions have is to model the interface around
MySQL API. Later, developers realize that thay can't map the modeled API
to implement other important drivers besides MySQL and they have to
redesign a significant part of the API.
Those are the perils of developing a database abstraction package and
making it available to the end users right away before it can be properly
abstracted to work well with most, if not all, DBMS.
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
--