Re: pearifying metabase: preparing phase 2

"Stig S. Bakken" wrote: > > On Mon, 2002-02-04 at 16:23, Tomas V.V.Cox wrote: > > Lukas Smith wrote: > > > > > > > Hi again Lukas, > > > > > Something that I would really like to see is a testing suite for PEAR DB > > > so I can be sure that what I do remains compatible with the old PEAR DB. > > > It might not even have to be totally complete as even some tests will > > > make my life easier and my results more reliable. Thomas: you mentioned > > > you had something like this? Especially since my work will not > > > immediately replace PEAR DB this is generally a good idea to have and > > > even a better idea to have if I do not succeed or get hit by a bus :-) > > > > Is not my test suite :-) I've put instructions on how to run the tests > > in the TESTERS document: php4/pear/DB/TESTERS (php.net CVS) > > > > > One more question: > > > Is the DB_result object really that useful to accept the overhead? I can > > > obviously stick something like that in the final merged version or I can > > > emulate this feature for PEAR DB compatibility mode. What were the > > > reasons to do it (I assume extensibility)? Did they pay off? How > > > strongly does everybody feel about this? > > > > The DB_result is a good desing thing, but sadly it slows a lot the > > execution because of the method calling overhead. Some time ago I did a > > new test desing dropping DB_result, and the speed gain was amazing (~50% > > faster). Finally I didn't change nothing waiting for the new Zend > > Engine, but if that doesn't solve the speed problem my bet is for doing > > the change (but that's other story :-). > > > > In short for you, imo try to avoid using DB_result as an interface for > > the driver. > > I don't think you need to worry about that now. I have a better > solution coming up in PHP 4.2: aggregate(). This is a new function that > lets you import methods from another class into an existing object. > This means we can simplify the architecture by having DB_connection and > DB_result objects importing backend-specific stuff on demand. This will > speed up simple calls a great deal (since there is less code to be > loaded always), and should reduce the result call overhead by > eleminating one layer of calls. > Umm.. that sounds really interesting. I want to see it! :-) Tomas V.V.Cox