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 Christian Kassab <chris.kassab@gmail.com>
Full name Christian Kassab <chris.kassab@gmail.com>
Date 2007-07-19 07:25:22 PDT
Message Hi,

why stuff so much debugging functionality into Propel? It is bloated
as it is already. How about using debugging tools like xdebug and
Eclipse? Yes I know you can't look into what goes on inside PDO as in
what the final query string looks like after binding the
variables/parameters, but thats another story...

If you really need the lower level debugging inside Propel then add it
in a non obtrusive way by enabling dependency injection of classes
that subclass the default ones but add the debugging functionality and
then call the parent methods etc.



On 19/07/07, Hans Lellelid <hans at velum dot net> wrote:
> Oliver Schonrock wrote:
> > Cameron Brunner wrote:
> >> Silence is good bad or otherwise?
> >
> > Don't take offense please. I like the features, but I am not sure about
> > the implementation:
> >
> > - using static $query seems untidy
> > - using __destruct() can cause problems depending on your environment
> > - using direct var_dump() it not always suitable.
> >
> > if we are going to add this to the core propel repository, my view would
> > be that it should meet the same criteria as the rest of the code as a
> > generic, high quality toolkit.
> >
> > Part of the reason I focused on simple features was that it is not
> > obvious how to solve some of the above problems with the more advanced
> > features while adhering to the quality standards of the rest of the
> > code. ie can run in any environment, etc..
> >
> > Opinions?
> Without having looked at the code, I second this opinion. We definitely
> don't want to use var_dump, for instance, as this is not particularly
> useful when building webapps that don't return HTML (i.e. that return
> XML/XML-RPC, JSON, etc.).
> My input would be that we need the default PropelPDO to be as
> unencumbered as possible (fast). If we're going to keep all the debug
> stuff in a separate object, then it doesn't matter much how that
> performs. If, however, the aim is to merge this into PropelPDO, then we
> need to make sure that we're doing things in an optimized -- and yes,
> "correct" -- way. We definitely don't want to open the door for subtle
> PHP issues.
> One thing I have learned from using Propel + PDO in PHP 5.2.2 is that
> PDO is not particularly bug-free :) I have dealt with a number of
> segfaults that are directly traceable to PDO. Sometimes it is the
> result of a malformed query (why this segfaults, I have no idea) --- or
> use of PDO streams within user-defined stream wrappers. I *hate*
> debugging segfaults in PHP; what a waste of time. There's apparently
> some really messy stuff under the hood there :) Let's do what we can to
> keep it from rearing its ugly head for users.
> Hans
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org

Christian Kassab

+44 (0)789 4467 606
+49 (0)163 6360 939

chris dot kassab at binaryworx dot net
chris dot kassab at gmail dot com