Multi-tenancy support

[nitely]

Recently it came to my attention django-tenants and got me thinking about this.

Multi-tenancy support (for djconfig) is certainly possible to implement by storing the current request domain (a string) into threading.local().

_Why not implement it on top of Django's cache?_

The issue with this is round-trips for accessing every setting within a request cycle would be expensive for some projects. Making a single round-trip fetching all the config and storing it locally would put us on the same spot as having a local cache (as it is now).

_Celery_

I've no idea how django-tenants integrates with Celery, it's worth asking the devs if it does it out of the box.

_Feature description_

• All current unit test should pass without any modifcation
• There should be a DJCONFIG_TENANT_MODE = False/True setting
• A thread local should store the current domain. The domain should be setted within the djconfig middleware (if tenant_mode is True).
• When accessing and (re)loading the config, it should store/retrieve it into/from self._cache[_local.domain]

I've no desire to implement this myself, but a PR implementing the above description (assuming it works) with good test coverage would be welcome :smile:

[tylerecouture]

Just a note that my project will have to stop using django-djconfig because of its lack of multi-tenancy support! But, thanks for the package! It's done me well for the past few years.

[nitely]

@tylerecouture just out of curiosity, what do you use for multi-tenancy? django-tenants? nothing? how does your multi-tenancy works?

I wanna know what could be implemented to solve this in the future.

[tylerecouture]

We're using django-tenant-schemas https://django-tenant-schemas.readthedocs.io