Re: pearifying metabase: preparing phase 2

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. - Stig