Login | Register
My pages Projects Community openCollabNet

Reply to message

* = Required fields
* Subject
* Body
Send reply to
Author (directly in email)
Please type the letters in the image above.

Original message

Author Cameron Brunner <cameron.brunner@gmail.com>
Full name Cameron Brunner <cameron.brunner@gmail.com>
Date 2007-07-13 04:03:01 PDT
Message A - We need to store the entire query in memory if we are to do
duplicate query detection.
B - If we dont, we incur quite an overhead to do func_get_args and
call_user_func etc so if we dont we pay a penalty even in production
hence the way i did that
C - true, specially if you have unbuffered queries enabled, its just a
bit of a guide on what returns a lot of rows. We could also add a
memory usage check onto the dtor, that would be about when all rows
are hydrated... we could also add the true flag to the memory usage
functions, i dont know the difference tho
D - We can still add these into PropelPDO and since DebugPropelPDO
extends it that will run automatically still... nice and seamless and
easy... i have had propel's name cursed at work since we couldnt see
the final sql that was being ran easily (having to replace the ?'s by

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

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

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

Cameron Brunner

Want a better web browser?