Nicolas, chtito
We've already been investigating on this one, and using the databases.yml
for all tasks actually means appending an application name to the commands.
On the other way around, it is not satisfactory either: using the propel.ini
for the propel-load-data is not enough, because we need information from the
databases.yml (such as encoding) that are not there. Plus, think about the
way to handle multiple schemas and multiple connections: the
propel-insert-sql and propel-build-schema tasks would have to be rewritten
to work in these cases.
Our conclusion was: This is too much change (and work) for the 1.0.
Repeating the DSN once is not that big a deal, and the book documents it
fine.
So feel free to open a ticket, we'll investigate after 1.0.
François
-----Message d'origine-----
De : [email protected] [mailto:[EMAIL PROTECTED] De
la part de chtito
Envoyé : mardi 16 janvier 2007 22:33
À : symfony developers
Objet : [symfony-devs] Re: DB settings in propel.ini and databases.yml
Nicolas: you are right of course. Propel.ini database settings should never
be called. They are called because of the propel legacy machinery. There is
also another reason: the database settings of databases.yml are environment
dependent. Using databases.yml would mean to append an environment argument
to all the propel tasks (as is the case for load-data, for example).
Of course it would be a great enhancement if the database settings of
propel.ini were removed. It would be much less confusing too. I also
remember François suggesting the same thing. What about opening a ticket?
On Jan 16, 4:17 am, "Tamcy" <[EMAIL PROTECTED]> wrote:
databases.yml is needed for runtime, while propel.ini is for
build-time (generator).
The only overlapping area is the connection url, but you probably
won't run insert-sql or so in a production environment. And well...
even I use insert-sql or friends sometimes I don't want it to be
executed against the project
database I'm working on. And finally: when you run propel's phing
task, it has no knowledge about your symfony project, including
databases.yml.
On Jan 16, 2:10 am, Nicolas Perriault <[EMAIL PROTECTED]>
wrote:
> Rick wrote:
> > The reason it is not in the databases.yml is because symfony is
> > ORM independent. Each ORM has its own settings and
> > configurations, so any propel-specific settings must be handled by
> > its own config file.Yes, but database settings are already defined
> > in databases.yml :)
> So shouldn't Propel use settings provided in this file ?
> The Doctrine plugin works this way and I think it's simplier and DRY
> compliant...
> ++
> --
> Nicolas Perriault http://www.clever-age.com
> Clever Age - Conseil en architecture technique
> GSM: +33 6 60 92 08 67 Tél: +33 1 53 34 66 10
> Clever Age vous invite à ses
> petits-déjeunershttp://www.clever-age.com/actualites/petits-dejeuner
> s/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
