Re: [PHP4BETA] DB in PEAR and other questions

On 6 May 2000 12:3:6 -0200, "Manuel Lemos" <mlemos@acm.org> wrote: > > 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. > Manuel, you have pointed out valid issues for designing an abstraction layer which is DBMS neutral, however this is not the only purpose for having an abstraction layer over DBMS calls. One of the first things I did when I started working with php3 was write a light weight wapper class for dealing with mysql. This was not specifically so that the code would work with every other DBMS that has and will ever be written, but to make my code easier to read and maintain. One abstraction layer that is 100% portable is not the issue raised here. I think that Andrew has raised a very valid question. Mysql doesnt support transactions and the PEAR DB class returns a constant to identify this. Why shouldnt this occur in the reverse situation for a DBMS that supports transactions but not last insert id ?? Regards, Alan van den Bosch Sanguis Pty Ltd /* All generalizations are false. */