Hi,

I'm nearly finished too, i added a __sleep method returning an empty
array to sfDoctrineDatabase so i dont need to scrap the whole context.
I'll submit that patch when i'll have some time (and the plugin too if
the patch is accepted).

Regards,

Zs.


On 2/20/08, Bernhard Schussek <[EMAIL PROTECTED]> wrote:
> Hello Zsolt,
>
>  I already ported sfErrorLogPlugin to Doctrine for private purposes. A
>  different solution than yours (although a little hacky) is to override
>  the sfWebRequest object (via factory) and add a __sleep method that
>  unsets the associated context object.
>
>  Regards,
>
>
>  Bernhard
>
>
>  On Feb 11, 2008 9:35 AM, Zsolt Takács <[EMAIL PROTECTED]> wrote:
>  >
>  > On a sidenote im working on porting the sfErrorLogPlugin to Doctrine.
>  > It requires the serializing of the request object to work, but that
>  > means serializing the sfContext object, then the sfDatabaseManager
>  > object, and in case you are using Doctrine this leads to trying to
>  > serialize the PDO connection object, which results in a fatal error.
>  > So i could use a factory for the db manager class, to include a
>  > __sleep method.
>  >
>  > Anyways i'll make a patch for sfDataBaseManager, and create a ticket
>  > when i'm done.
>  >
>  > Zsolt
>  >
>  >
>  > On 2/11/08, Dustin Whittle <[EMAIL PROTECTED]> wrote:
>  > >
>  > > Fabien,
>  > >
>  > > >>
>  > > >> It seems the usage of the environments in config files is 
> inconsistent.
>  > > >> Since the configuration cache is stored based on environment, is 
> there any
>  > > >> reason to restrict certain files from not having support for 
> environments? I
>  > > >> think configuration files like filters.yml and view.yml should be
>  > > >> customizable based on environment.
>  > > >>
>  > > >> Also, there is some inconsistency with default/all. Can we change all 
> to
>  > > >> default for consistency?
>  > > >>
>  > > >> Also, what do you think about adding database manager as a 
> factories.yml
>  > > >> factory?
>  > > >
>  > > > After some thoughts, I don't think this is a good idea. As I said
>  > > > before, sfDatabaseManager is already an abstraction class. Moreover,
>  > > > this class is used at several places to initialize Propel. So, if you
>  > > > define your own class, a lot of things will break.
>  > > >
>  > >
>  > > I see what you mean. This suggestion was more about making all of the
>  > > factories customizable, rather needed for a real purpose.
>  > >
>  > > >> There is a view_cache factory, but I think we should add a cache
>  > > >> factory as well (for internal caching ­ apc/xcache/eaccellerator) and
>  > > >> optimize some parts of the core to use apc/xcache (like caching the 
> path
>  > > >> lookups for finding templates + configs, or caching routing)..
>  > > >>
>  > > >> Also, is it just me or could the web debug timers use a refactor? 
> (they seem
>  > > >> to always not add up)
>  > > >>
>  > > >> Any thoughts / questions / concerns?
>  > > >>
>  > > >> - Dustin
>  > > >>
>  > > >>>
>  > > >>
>  > > >
>  > > >
>  > > > >
>  > >
>  > >
>  > >
>  > > >
>  > >
>  >
>  > >
>  >
>
>  >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/symfony-devs?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to