Add system check for SITE_ID.

[Gagan Deep]

The "sites" framework requires to set a SITE_ID to specify the database ID of the Site object associated with that particular settings file. From the documentation, it can be interpreted that it should be an integer. But, it can also be set to a string literal('1'). I know this is wrong, but the Django accepted it and worked with it anyway without showing any warning or error.

The problem arose with SITE_CACHE. It was not getting invalidated when the Site object is updated. The reason is the code which handles invalidation uses primary key of instance object which will be an integer. Therefore, the cache is never invalidated.

try:
    del SITE_CACHE[instance.pk]
except KeyError:
    pass

​Please see complete code on GitHub.

Since working of an element of Django is dependent on this setting, I suggest that there be a validation test for SITE_ID.

[Adam Johnson]

Part of the problem here is that Site.objects.get(pk=some_string) works because the database uses [SQL implicit type conversion](​https://adamj.eu/tech/2020/03/06/sql-implicit-type-conversion/) to cast the string, but we need a consistent value within Python.

If it's only the site cache that's affected we could make SITE_CACHE a subclass of dict that casts keys but that seems like overengineering when a system check would provide enough validation at the boundary.

[Mariusz Felisiak]

... it can be interpreted that it should be an integer.

It's clearly stated in ​docs: "The ID, as an integer, ..." but I agree that we can add a system check, e.g.

sites.E003: ``SITE_ID`` must be an integer.

[Mariusz Felisiak]

​PR

[Mariusz Felisiak <felisiak.mariusz@…>]

In 41065cf:

Fixed #31802 -- Added system check for non-integer SITE_ID.

[Gagan Deep]

It's clearly stated in ​docs: "The ID, as an integer, ..."

I must have overlooked that. Thanks for bringing it. :)