> Under your proposal, I need to write DATABASE_ENGINE and DATABASE_NAME
> once for each application, because there is no way to group the
> information is even one of my applications needs a different database.
> That seems like a lot more configuration (longer config files are harder
> to debug, too).
A few counter-arguments...
If you have five apps that all use the same db, then you don't need
DATABASES at all.
Tuples are hashable:
DATABASES = {
('myproj.fred', 'myproj.ethel', 'myproj.lucy', 'myproj.ricky'): {
'DATABASE_ENGINE': ... }
}
Settings are python files: :)
common_db_settings = { 'DATABASE_ENGINE': ... }
DATABASES = {
'myproj.fred': common_db_settings,
'myproj.ethel': common_db_settings,
'myproj.ricky': common_db_settings,
'myproj.lucy': { 'DATABASE_ENGINE': ... } # she's uncommon
}
Lastly, as I have it now, items in DATABASES inherit from the default
any settings they don't specify themselves, so that should also reduce
config file length when N out of M apps use the same connection.
> I would prefer to get rid of the option of putting it in models
> altogether
You're right, the connection information should belong to the manager.
In my reply to Jacob, I suggested manager.db as the holder for all of
the connection info, which would give you manager.db.connection,
manager.db.backend, etc.
> I am unconvinced. :-)
I have more arguments. Or I will in the morning. :)
JP
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django 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/django-developers
-~----------~----~----~----~------~----~------~--~---
