On Wed, 2006-06-07 at 22:25 +0000, [EMAIL PROTECTED] wrote: [...] > However, I've run into a problem that can't be fixed with little > patches, in django.core.management. Specifically, all of the many > get_sql_* functions in there pull together sql from multiple models and > execute it all with the default connection. That's not going to work if > model A and model B want different connections. > > I'd argue that the right solution here would be to push the brains > farther out to the edge. Have management functions call class methods > on models to execute table creation, initial data loading, etc, rather > than having them poll the models for information and construct and > execute the sql themselves. Something like: > > def install(app): > # ... validation, start a transaction, etc > for model in models.get_models(app): > model.install() > > Rather than the current: > > def install(app): > # ... > sql_list = get_sql_all(app) > > try: > cursor = connection.cursor() > for sql in sql_list: > cursor.execute(sql) > > That would be a pretty substantial change, but I think it would open up > a lot of interesting possiblities for models that behave differently > from the default -- and it certainly would make supporting multiple > databases a whole lot easier.
I don't think you can completely remove the controller portion here, although you can push a lot of the mechanics down into the model managers. The difficulty is that models do not exist completely independently of other models. Think about relations between models. ForeignKey and friends now have to be implemented differently or can only apply to models using the same database. And, in any case, they need to know the table name (and quite possibly database name and connection proxy) for the related tables. So you are going to have do a pass through all the models and build up the graph of dependencies and make that available to each model at construction time as well, aren't you? [As an aside: I think we are also going to discover that ForeignKey is unfortunately named, because one-to-many relations to tables in another database is not complete nonsense; I've worked on systems in the past that separated frequently read tables from frequently updated, less frequently read tables for performance reasons.] > > What do you all think? Nice work. :-) Best wishes, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
