The patch won't be applied as it opens a lot of other issues. The sfConfigCache relies on an application being supplied and can't work with only a project configuration.
I've tried before and I've never applied it because of a lot of problems... which I can't remember right now. You can create a ticket with the patch attached and we will work on this after 1.1. But we won't "fix" this for 1.1. Fabien Carl Vondrick wrote: > Is there a reason why sfDatabaseManager must depend on > sfApplicationConfiguration? Can't it depend on sfProjectConfiguration > instead? > > If we remove this dependency, then we can use symfony's database manager > outside of an application context. Then we can remove the application > argument on the propel:data-load task (and prevent me from adding it to an > sfSearch task). > > Initial patch for this is attached. If it's viable, I will create a ticket. > This patch simply moves two methods to sfProjectConfiguration and writes the > configuration cache to %SF_ROOT_DIR%/cache/default/config when outside of an > application context. > > The patch has an unattended side-affect of causing the Propel functional > tests > to fail. I will fix these if/when this patch is accepted. > > Carl > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
