A - We need to store the entire query in memory if we are to doduplicate query detection.B - If we dont, we incur quite an overhead to do func_get_args andcall_user_func etc so if we dont we pay a penalty even in productionhence the way i did thatC - true, specially if you have unbuffered queries enabled, its just abit of a guide on what returns a lot of rows. We could also add amemory usage check onto the dtor, that would be about when all rowsare hydrated... we could also add the true flag to the memory usagefunctions, i dont know the difference thoD - We can still add these into PropelPDO and since DebugPropelPDOextends it that will run automatically still... nice and seamless andeasy... i have had propel's name cursed at work since we couldnt seethe final sql that was being ran easily (having to replace the ?'s byhand)

Always plenty of options, i have been wanting a way to automaticallyprofile an application in development and when a 'slow' or 'expensive'(memory wise) query is ran then to display it. I was considering aSmarty debug style popup to be able to be enabled...

Anyway, thats where i was going with it. I think i answered everythingin your email but im freezing so im gonna go crawl under a blanketinstead of sitting here. Hit me up with any questions or thoughts onthis.

On 7/13/07, Oliver Schonrock <oliver at realtsp dot com> wrote:> Cameron Brunner wrote:> > I would be more interested at this point in offering DebugPropelPDO as> > a connection object type and adding a full array of debug info (query> > timing, counting, dupe query detection) to it and have a flag that> > switches to it when requested. Query timing generally interests me> > more than the count.>> I agree with much of this. Query timing would certainly be useful.>> There are questions about the tactical details, most of which are> stylistic and there is no "right" answer:>> a) do we want a full array of sql strings in an array in memory? Would> this extra information be better in the query log which is already> storing the sql strings (if configured in runtime conf).>> b) Do we want to have a "debug" switch in Propel to tell it which PDO> class to instantiate or just add the functionality to the standard> PropelPDO class and then enable the extra logging/counting with> build|runtime config (similar to log now). If we do want to instantiate> different PDO classes, then would we rather pass a Classname into propel> via the build|runtime config? This would give the Propel user lots of> flexibility>> c) memory usage reporting as implemented in Cameron's patch may be> slightly misleading as the Stmt::execute (et al) calls don't really use> much memory compared to instantiating the objects from the result set.> Even if you have mysql_buffered_query turned on, the memory used for> buffering the query result is not reported by memory_get_usage(),> although you will see your apache process grow in ps|top (substitute> your own tools here for non *nix/apache users).>> d) If we are going to provide a PDOStatement extension as part of> propel, then this gives us the option of moving the Propel::log() call> from PropelPDO::prepare() to the same 3 places where I had incQueryCount> and Cameron had debugQueryLog() (ie 2 places in PropelPDO, and one in> PropelPDOStatement). This would mean we make log file entries when the> query is actually run rather than prepared plus allows the addition of> the extra info (like query time) into the log file.>> Thoughts? Opinions?>>> -->> Oliver Schonrock>>>