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-19 13:32:38 PDT
Message On 7/19/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.).

See my previous message

> 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.

No way should the debug stuff be in the main propelpdo object, its all
heavyweight and there are overheads for it all. i would never
recommend this went into the 'production' connection and for that
matter im also getting to the point where i want to take the logging
methods out of the standard 1 and put them into the debug driver to
make it even faster

> 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
>
>


--
Cameron Brunner

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