Re: MDB_Extended

Hi Lukas, do you think, there is a common problem with the "module architecture" or is it just the Extended module that makes you worry? Doesn't return loadModule() always a reference to the loaded module? Did you try using this in methods? $ext = $mdb->loadModule("Extended"); $ext->queryOne(...); Wouldn't this reduce code? Maybe a abstract kind of iterator should be integrated to work with both, unbuffered and buffered lists in the same way? Another thing: Is there a Common.php in MDB/Modules/Native? It doesn't exist in the CVS. Remember MDB/Common.php line 1574: Instead of "return $value;" it should return an error, something like "declaration not found" or what else is $value? And finally: A "little" feature request for LOBs: Maybe it would be usefull to have a factory for reading and writing LOBs for example to/from files, FTP, Streams, and other stuff!? Please let me know what of the ideas are bull shit, so that I can improve my comments ;-) Regards, Matthias Lukas Smith wrote:

Hi, I) I was wondering what you all feel about MDB_Extended. The entire reason for its existence is to cut down the amount of code inside the main class. I for one am not too happy with this. The situation is that I have two usage scenarios: 1) I use unbuffered queries 2) I fetch all data from MDB in one go and free the result set 1) is a new feature in MDB 2.x to improve memory consumption on really large result sets. However I rarely use it ATM because it means that I have to loop through the result set and I prefer to loop through arrays. 2) means that now I have to load the extended module and type and additional "extended->" all over the place. This is somewhat annoying. Also in order to not require the extended Module in side the manager classes in MDB I in effect have to duplicate the relevant code in tons of methods. This all makes me think that maybe atleast the query(One|Row|Col|All) methods should be moved back into the core of MDB. Furthermore I would like to point out that the query(One|Row|Col|All) type method will also be featured in the php5 only pdo database ext. However then the question is what happends to get(One|Row|Col|All) methods. Should those be moved back as well? Should I just drop the class entirely? II) In the pdo database ext the queryCol method also handles the functionality of queryOne. It therefore does not have a queryOne method. Basically there is an optional parameter specifying if you only want to fetch the first row. Essentially I could remove several methods from MDB that way (thereby reducing the amount of code those method occupy in MDB_Extended, which may affect your view point in I) above): a) queryOne (handled by queryCol) b) fetchOne (handled by fetchCol) c) queryRow (handled by queryAll) d) getOne (handled by getCol) e) getRow (handled by getAll) However take into account that especially (query|get)All already takes a fair amount of parameters. Therefore it might make sense to not do the changes described in c) and e). 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