Re: Re: [metabase-dev] pearifying metabase: phase 1

Manuel Lemos wrote: > > Hello, > > Lukas Smith wrote: > > Minor: > > - fetchmode (minor) > > This can easily be emulated because Metabase supports random access to > database rows. I guess that he was reffering to the type of that you expect from a fetch action. Ex, PEAR DB supports now: an ordered array, an assoc array and a configurable object (see the setFetchmode() method for more info). > > - DSN support (minor) > > This was planned to be added to Metabase similarly to JDBC and it seems > to PEAR-DB. I just disagree that the database name be required in the > DSN as it seems that PEAR-DB requires. Metabase lets you change the > database to each you want to connect in the with the same driver object > instance. Actually you may perform queries to a server that has no > databases installed. So what PEAR-DB does? I haven't checked, but does > it fails to connect because you did not specify a database name? Yes, we expect from the user to connect to a database :-) Anyway our DSN parse function does not require any field, it's a task from the driver to check what it needs. > > - Missing Drivers > > Frontbase (minor?: will the frontbase guys write one/modify the current > > for us?), The Frontbase guys have yet support for both PEAR DB and ADODB. > > LDAP (minor: I want it myself, but the driver is fairly new and not that > > "feature rich" yet, so we should be able to port it) > > Yes, this is a long shot that in the end you may realize that doesn't > quite fit in a database abstraction layer that is supposed to execute > SQL queries. What is different for us in PEAR, is the fact that we don't expect that will be able to do the same with all the drivers. This philosophy allows us to give support for things like LDAP or DBASE. This doesn't mean that the support for real databases engines should be complete and robust. > > - tableInfo (minor: metabase allready has some of those features) > > Actually Metabase does not have this yet. I want to add it because I > want Metabase manager to be able to reverse engineer schemas of > applications already installed by traditional means, to encourage people > to migrate to Metabase and use the database independent schema > definition. tableinfo is a hard point, because it's so difficult to implement in some drivers (even more info from a result). If we could cooperate for trying to complete for all the drivers we will be able to do cool things in the future. > > - flexible default behavior (minor: shouldn't be too big of a deal to > > implement) > > What does this mean? Hehe, same here :-) > > Small: > > - Error support (small?: maybe not a big deal through the use if > > customer error handler feature of metabase) > > Yes, Metabase error handler callback should be sufficient to implement > whatever error handling methods provides. Metabase passes more > information to the error handler callback than just the error string > returned by the Error() driver method. If you don't want to clone all the actual functionality of PEAR.php, just use it in the future. > > - transaction (small?: I haven't look at either metabases' nor pear db's > > implementation) > > I don't see a problem here. Metabase eventually will implement more > transaction related things soon. Just to give you information Lukas, the transaction stuff works in PEAR DB so: $db->autocommit(true|false); ... $db->commit(); or $db->rollback(); > > - DB_result object (minor) > > I think you have all in Metabase that you need to emulate PEAR-DB and > probably more. What's the problem here? IMHO you haven't to clone to architecture, only the functionality. > > - error messages (small?) > > Error messages is not a problem. What Metabase does not provide is error > number abstraction. > > The way I see it, errors are fatal conditions and so in each situation > they should be handled the same way regardless of the type of error that > happened. So, I never implemented error abstraction because I don't see > much point in having a way to distinguish error types programatically. > Usually an error string is enough for logging so the programmer can read > the exact error message that the database back end returned along with > some context information provided by Metabase but all in text because > that is what is useful for humans (programmers). See some examples on how the abstracted error messages are a real good thing: // Create tables on demand $dbh->expectError(DB_ERROR_NOSUCHTABLE); $res = $dbh->query('DELETE FROM categories'); $dbh->popExpect(); if (DB::isError($res) && $res->getCode() == DB_ERROR_NOSUCHTABLE) { $dbh->query('CREATE TABLE foo ..'); } // This will try to insert a row. If the primary key already // exists, then the data will be updated. This system will // avoid any race condition. $dbh->expectError(DB_ERROR_ALREADY_EXISTS); $err = $dbh->query('INSERT INTO ...'); $dbh->popExpect(); if (DB::isError($err) && $err->getCode() == DB_ERROR_ALREADY_EXISTS) { $dbh->query('UPDATE table SET ..'); } > Also, it seems to me that error abstraction is quite utopic because an > operation can fail in thousands of ways and a database can return > different error codes for each so it will be an hell to categorize all > the codes even if the driver can antecipate the meaning of all of them. Our system is working good, I don't see the real problem. > Another thing that I disagree in PEAR-DB design is that certain > conditions that are not errors but just status information is abstracted > as errors. For those conditions there should be functions to retrieve > them. For instance, querying affected rows or if a driver supports a > certain capacity. > > If a programmer calls a function that is not implemented for a certain > driver, that is a programming error, not a run-time error. The program > should handle that as a fatal error with any need to distinguish what > type of error was that. The right way for programmers to handle the > (lack of ) ability of a driver to implement a certain capacity is to > query the driver before trying to use it. So there is not need for > abstracting this type error either. Yes, perhaps we could reorder the error numbers so people could differentiate between database errors and developer errors. > > - getListOf (small?: Thomas was not sure about the status inside of PEAR > > of these features) > You can get info of the status on this in the STATUS document: php4/pear/DB/STATUS (php.net CVS) Could be great if more people helps here to get it completed. It's quite useful (I'm needing it a lot in the developing of PDBPLUS). > > > Large: > > - LOB support (large?: I haven't look at either metabases' nor pear db's > > implementation) > We haven't LOB support. > > - API changess like function naming, parameter orders, coding style > > stuff (large: a lot of work but nothing too complicated) > > Forget it for now. Keep in mind that at this point you should be > concentrated on making the proof of concept which is wrapping PEAR-DB > API around Metabase API and demonstrate that it works as needed so > nobody developing PEAR-DB applications need to change their code and the > same for Metabase based applications. Well, to pass the tests at least function naming and parameters order should be there no? > > Unsure: > > - storage.php (?: is this used a lot? Will this work out of the box once It's a class that uses PEAR DB, not part of PEAR DB itself. > > - different ways of how data is stored in the DB for emulated features: > > sequences, NULL ..? (?: this is actually one of those most difficult > > areas .. hopefully a simply convert script could take care of it . but > > its definitely ugly if certain features have been emulated differently > > in the db) > > Yes, personally this is another thing that I quite don't agree on some > PEAR-DB implementations. PEAR-DB should not be executing implicit schema > management functions on demand because for security reasons it may not > be desired that the current application user have privileges to do it. > For instance, it is wrong to create sequence emulation tables on demand > because as I said the application user may not have privileges to create > tables. That's why the nextID() method accepts an extra param (bool) $ondemand :-) Tomas V.V.Cox