Login | Register
My pages Projects Community openCollabNet

propel
Reply to message

* = Required fields
* Subject
* Body
Attachments
Send reply to
Topic
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-14 01:26:36 PDT
Message I'm tempted to move any query logging support into DebugPropelPDO and
make the 'production' PropelPDO as fast as possible after splitting
this off...

On 7/13/07, Hans Lellelid <hans at velum dot net> wrote:
> 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.
>
> Hans
>
> 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
> >>
> >>
> >>
> >
> >
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>


--
Cameron Brunner

Want a better web browser?
http://www.spreadfir​efox.com/?q=affiliat​es&id=182780​&t=1