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

> > - 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? so I will not worry about doing this myself for now > > - 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. Well you can get the column names in metabase iirc. But if you are working on this I will also not worry about this for now. > > - getListOf (small?: Thomas was not sure about the status inside of PEAR > > of these features) > > I don't know what is this. PEAR DB manual: DB::getListOf() -- list internal DB info I read somewhere else that this method gives data about users and the database etc ... But Thomas was not sure how far development in this method has gotten. What is the status of the LOB support in PEAR DB .. is this experimental right now? Is this used? Do I have to worry about backward compatibility or is it enough to provide the functionality that metabase offers (which workes quite well for me) I will do some function renaming, but I will only do that for my testing enviorment. So I will only do this for mysql (I think our DB testing server is currently being used for something else so I don't have anything else easily available) so this will not be all that much work. Generally I am mainly familiar with mysql (I have done some development on Postgresql and a bit of tyoing around with Oracle and DB2. So if you guys can think of any pitfalls that are specific to certain RDBMS drivers but that need special handling inside the basic package (well theoretically this should not matter since the RDBMS specific driver should allways be able to overwrite any core methods ...) please let me know. 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 _______________________________