django SITE_ID 通过查询

Question

I have a django app. I'm adding a second site.

So now I need to set SITE_ID correctly. This is easy enough, except that since it is the primary key id in the Site table, this means the value is dependent on the order in which sites have been added (and, eventually, deleted). That's fragile, without even discussing how developers will sort this if they've done any scratch work in that table. Much better to set it by query.

SITE_ID = Site.objects.get(name='my_site_name').id

But the settings_myapp.py file, which sets WSGI_APPLICATION , is pretty much the only one that might know which app I'm running. I could try modifying settings in that site-specific settings file, but importing settings at that point leads to an error that SECRET_KEY is not yet defined.

Is there a robust way to do this?

Answer 1

This is a summary of how I solved the problem I stated in my question. Unbeknownst to me when I asked the question, there are actually several facets demanding different approaches.

A bit of middleware helps enormously for deployed instances (ie, not dev). This solution provides a django 3.1 ready code snippet, as a solution that existed in times past is no longer compatible with modern django.

For developers, I added this to my settings.py :

DEFAULT_SITE_ID = os.getenv('DEFAULT_SITE_ID')

And so the snippet above becomes this:

class DynamicSiteDomainMiddleware:
    default_site_id = None

    def __init__(self, get_response):
        self.get_response = get_response
        # One-time configuration and initialization.
        self.default_site_id = settings.DEFAULT_SITE_ID
        if self.default_site_id is not None:
            current_site = Site.objects.get(id=self.default_site_id)

    def __call__(self, request):
        if self.default_site_id is None:
            try:
                current_site = Site.objects.get(domain=request.get_host())
            except Site.DoesNotExist:
                current_site = Site.objects.get(id=settings.DEFAULT_SITE_ID)
        else:
            current_site = Site.objects.get(id=self.default_site_id)

        request.current_site = current_site
        settings.SITE_ID = current_site.id

        response = self.get_response(request)
        return response

In other words, if a developer has set DEFAULT_SITE_ID (eg, on the commandline when invoking manage.py ) that value is used. Otherwise, we look at SNI on requests.

This leaves one bit of the puzzle unanswered: what to do about urlpatterns ? I've two sites (soon three) that have slightly different URL schemes. But in the main urls.py , the site information is not yet available under this clever middleware solution, as urlpatterns is (naturally and necessarily) set before any requests happen.

The approach that smells best to me sets an environment variables so that settings.py can set ROOT_URLCONF for its specific case.

ROOT_URLCONF = os.getenv('ROOT_URLCONF', 'transport_nantes.urls_tn')

An apparent disadvantage is that we end up stuck with two incompatible mechanisms for setting the site data: DEFAULT_SITE_ID + SNI and also ROOT_URLCONF . This isn't as bad as it seems, however, since these are two independent aspects of the problem: what site I am and what URL scheme I mean to have. This required a very small change to production and staging deployment code to set the appropriate environment variable.

Finally, in each of the url_XYZ.py files, I set a variable for the base template for that version of the site. (At issue is that the links are different. If it were just changing the logo, it would be easier.) I pass that value in a dict to the included url files, and so I can use that knowledge when rendering views, even though view functions are often shared amongst several sites and URL schemes.

So why not set an environment variable for the SITE_ID as well? This goes back to the initial question: the site id is fragile, being the primary key in the sites table. It is reasonable to imagine some bit of maintenance that leaves the sites table unchanged except for a changed primary key (for example, an inadvertent deletion followed by recreation of the record). So looking up values by name is more robust.

On the other hand, the ROOT_URLCONF variable has the advantage that it's not tied to the sites table. For example, site X has a certain URL scheme, which is true whether X is running in production or staging or testing, all of which have different FQDN's.