> If so, is this something that would work reasonably seamlessly on top of > J Pellerin's multi-database Summer of Code work (different engines => > different connections => essentially different database for that model, > so it falls out of his configuration changes)?
Sort of. But mostly not. These are more per-model attributes... though I suppose you could do this with a custom manager for the model that overrides install() to use a different sql generator that does whatever you want. Then your problem would be finding a place to put the extra options sql or flags, since Meta is closed (in the current design) and can't be extended to accept user-specific options values (which I think is a mistake, but that's another discussion entirely). Of course, total control over table creation is possible with initialdata now: DROP TABLE foo; CREATE TABLE foo ( .... ) with_flying_monkeys; Which is a bit more hands-on, but a lot easier than patching together a manager to squodge extra bits of sql on the end of what its builder builds. JP --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
