I think a component system might be nice -- have light uniform API
classes and then additional components / tools to handle the real
abstraction stuff. Kinda like MDB currently breaks out the "Manager"
classes. I think it would also make sense to break out the metadata
classes. Personally I really like the JDBC model, and myself have
been
doing some work on a JDBC-like Uniform API for PHP5/ZE2 (some prelim
info at http://creole.ws).
I am already on it for MDB 2.0 :-)
Cool! I think that the metadata API has been a weakness of PEAR::DB (compared to, e.g. ADOdb). On the other hand when I've looked at the disparity in metadata information availible through PHP native methods, I think I've understood why the PEAR::DB metadata has been pretty basic so far.
There are also a lot of convenience functions that maybe really don't
need to be in the core uniform API class. Things like getOne(),
getAll(), etc. (which I myself use quite frequently) should maybe be
in
an optional component -- so that the core classes can be kept smaller.
Agreed! I think it makes sense to minimze the convinience methods
Cool too :-) I think that having streamlined uniform API classes would make it more sensible to use (M)DB in other large-scale
applications. E.g. in a big o/r persistance layer it would be nice to have a very quick (and convenience-free) db API. For RAD / simple web apps the conveniences are very, very nice IMO and so having that be an option is attractive.
Hans