RE: [PEAR-DEV] Re: [metabase-dev] pearifying metabase: phase 1

Hello, Thanks for your reply Thomas > > > 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). Correct ... For mysql this will for example require switching to mysql_fetch_array from mysql_fetch_row and then adding the necessary parameter to specify how the data should be returned (numbered, associative etc.) > > > - 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. Well using the DSN stuff in PEAR basically is just an alternative to submit the database relevant information as an array ... So using the DSN will just execute a setupdatabase along the way .. So no problem there ... I will just take the current parseDSN function and stick it into the merged code ... > > > 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. Yeah ... most likely the LDAP stuff will be limited to not include all functionality ... and that is fine with Metabase too (it will just fail on some of the conformance tests) .. but as I also mentioned maybe the LDAP stuff would fit better into the storage package that works on a higher level of abstraction. But that is just an idea. > > > - flexible default behavior (minor: shouldn't be too big of a deal to > > > implement) > > > > What does this mean? > > Hehe, same here :-) just all of those defines for how function are to behave if certain parameters are not set .. for example: define('DB_FETCHMODE_DEFAULT', 0); > > > - 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. So I guess it would make sense to use the stuff that PEAR currently has and work from there? > > > - 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. I just want to make sure that everybody is happy with the merged code :-) So the question (as I have stated in another mail) is if a separate result object is good or not. Or better if I will integrated the result object in the merged version or if I will emulate the result object in the merged version. Currently I don't see all that much use in a separate class to handle result sets. > > Yes, perhaps we could reorder the error numbers so people could > differentiate between database errors and developer errors. Sounds like a good idea .. For the error messaging abstraction I will just take what PEAR has to offer right now ... so no big problem there either > > > - 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). Ok, Metabase does not have anything like that (I will look at the status document when I get the time) but I guess that will be another feature I will take from PEAR > > > Large: > > > - LOB support (large?: I haven't look at either metabases' nor pear > db's > > > implementation) > > > > We haven't LOB support. Ok, then I will not worry about LOB support, and I will just provide Metabases functionality Best regards, Lukas Smith smith@dybnet.de _______________________________ DybNet Internet Solutions GbR Alt Moabit 89 10559 Berlin Germany Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de info@dybnet.de _______________________________