On Sep 10, 7:13 pm, "Justin Fagnani" <[EMAIL PROTECTED]> wrote: > For application-wide db connections, I think it'd be much easier and > more portable to choose the connection in settings.py rather than in a > Model.
That's a very interesting point, and one I hadn't considered. It makes sense to allow people to over-ride the connection used by an application they didn't write - for example, people may want to tell Django that django.contrib.auth.User should live in a particular database. Further-more, just allowing people to over-ride the connection used for an existing application isn't enough - you need to be able to over-ride the default get_connection method, since you might want to shard Django's built in users (for example). This in definitely one of the use-cases we need to cover. I'm not sure of the best way to handle it though. The way I see it the options are as follows: 1. Monkey-patch the existing User manager. 2. Have a setting which lets you say "for model auth.User, use the get_connection method defined over here". This is made inelegant by the fact that settings shouldn't really contain references to actual function definitions, which means we would probably need to us a 'dotted.path.to.a.function', which is crufty. 3. Use a signal. There isn't much precedence in Django for signals which alter the way in which something is done - normally signals are used to inform another part of the code that something has happened. I'm not overjoyed by any of these options. Cheers, Simon --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
