Re: another MDB module

Hi Lukas Smith, some days ago you wrote:

Hi, I am thinking about adding another module to MDB which focuses on exposing more native functionality. Please, do it ;-)

Stuff that could potentially end up in there is the following: - deleting of PostGreSQL LOB's (currently not possible because they are stored as separate objects in the database) - auto_increment - .. your favourite method here the advantage of having those methods available through MDB is that they would behave similarly. That is the API would have a similar feel, they would use the connection resources from MDB and other needed functionality provided through MDB, they would use PEAR error handling, similar functionality available in multiple databases would have the same API (like auto_increment) I think this is a good idea, although it breaks a little bit

the idea of writing applications db independent. But there are so many nice db-specific features and it would really be nice to be able to use them *optionally* trough MDB! Well, I can already do this by simply checking the used phptype and for example only use auto_increment if phptype == "mysql". But if you want to get this work with features that are supported by some DBMS (not all) it would be useful to manage this trough a module. I could imagine an example like that: if (supports native feature x) {

    use it and be happy

} else {

    do it in default/db independent way

} Maybe a plugin system similar to Smarty would help to use native methods on demand? But what about the property MDB_Common::supported isn't it a good place for additionaly native functions? Or should this only be used for common functionality?

I don't have a good name for the module yet. First idea was to use "Native". Also I would appreciate suggestions (ideas + code) for other stuff that could go in there. Maybe this could also be used for triggers, stored procedures,

native types? Simply for all that is not available in all DBMS ;-) Maybe another way of thinking is also to implement things that miss in some DBMS or workarounds in MDB_Native, so that you could develope db independent again. And where a DBMS doesn't support a feature the workaround is used. Nice idea, but isn't it overkill? Hmmm, I'm a little bit confused about handle native stuff. But I see the need for it, as I need it also by myself for example to use triggers! Regards, Matthias

Regards, Lukas Smith smith@backendmedia.com _______________________________ BackendMedia www.backendmedia.com berlin@backendmedia.com Linn Zwoch Smith GbR Pariser Str. 44 D-10707 Berlin Tel +49 30 83 22 50 00 Fax +49 30 83 22 50 07