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 hlellelid
Full name Hans Lellelid
Date 2007-07-13 06:55:53 PDT
Message Just chiming in to say that all this makes sense to me :) I definitely
agree that a debug flag is a good idea. I think we should keep the
default PropelPDO system "production ready". We shouldn't need to swap
the PDOStatement object for non-debug PropelPDO, right?

I like the idea of moving the query logging into the
PropelDebugPDOStatement (or whatever it's called) class.


Cameron Brunner wrote:
> 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
> hand)
> 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
> this.
> 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