Multitenancy in Django using PostgreSQL as SAS ERP
A versatile framework for creating applications in Python, Django does not provide support for multiple tenants for a project instance, even when only the info is different. Since we don’t want to run many copies of the same project. Hence we use “Tenants” for the the following :-
A) Multiple customers running on an equivalent instance
B) Shared and Tenant-Specific data
C) Tenant View-Routing
What are schemas?
A schema is often seen as a directory in an OS , each directory (schema) with its own set of files (tables and objects). It enables an equivalent table name and object to be utilized in different schemas without conflict.
Why schemas?
There are typically three ways for solving the multi tenancy problem in Django.
Isolated Approach: It separates databases. Each tenant has its own database.
Semi Isolated Approach: It uses a shared database for separate schemas. In this way there is one database for all tenants, but one schema per tenant.
Shared Approach: It uses a shared database for shared schema. All tenants share an equivalent database and schema. There’s a main tenant-table, where all other tables have a far off key they point to.
This application implements the second approach, which in our opinion, represents the perfect compromise between simplicity and performance.
Simplicity:This will barely make any changes to our current code to support multi-tenancy. We simply manage one database.
Performance: It makes use of shared connections, buffers and memory hence it has better performance.
There are up and down sides of each solution, for a more in-depth discussion, we can see Microsoft’s article on Multi-Tenant Data Architecture.
How it works
Tenants are recognised via their host name (i.e :- tenant.domain.com). This information is stored on a table on the general public schema. Whenever an invitation is formed , the host name is employed to match a tenant within the database.Whenever the invitation matches with the tenant, the search path is updated to use this tenant’s schema. So from now on all queries will happen at the tenant’s schema. For instance, if you’ve got a tenant XXX at http://XXX .example.com. any request incoming at XXX.example.com will automatically use XXX schema and make the tenant available according to the matched request. If no tenant is found, a 404 error is raised. This also means you ought to have a tenant for your main domain, typically using the general public schema. For more information please read the [setup](#setup) section.
Shared and Tenant-Specific Applications
Tenant-Specific Applications
Most of your applications are probably tenant-specific, that is, its data isn’t to be shared with any of the opposite tenants.
Shared Applications
An application is taken into account to be shared when its tables are within the public schema. Some apps add up being shared. Suppose you’ve got some kind of public data set, for instance , a table containing census data. You would like every tenant to be ready to query it. This application enables shared apps by always adding the general public schema to the search path, making these apps always available.
Installation
First step is to install django-tenants.
— — — >> pip install django-tenants
Basic Settings
We have to make the following modifications to our settings.py file.
Our DATABASE_ENGINE setting needs to be changed to
DATABASES = {
‘default’: {
‘ENGINE’: ‘django_tenants.postgresql_backend’,
# ..
}
}
Add the following in settings.py file .
DATABASE_ROUTERS = (
‘django_tenants.routers.TenantSyncRouter’,
)
Now add the middleware django_tenants.middleware.main.TenantMainMiddleware to the top of MIDDLEWARE, so that each request can be set to use the correct schema.
MIDDLEWARE = (
‘django_tenants.middleware.main.TenantMainMiddleware’,
#…
)
Make sure we have django.template.context_processors.request listed under the context_processors option of TEMPLATES otherwise the tenant will not be available on request.
TEMPLATES = [
{
#…
‘OPTIONS’: {
‘context_processors’: [
‘django.template.context_processors.request’,
#…
],
},
},
]
Only by using django we can’t implement multitenancy but by the use of “Tenant” we can easily implement the same with the excellent efficiency and enhanced performance.
Are you planning to implement Tenant in your ERP project? Oodles ERP is the CRM Software Development Company you need! Our ERP Software developers help you in integrating automated workflows in your application. For more details, get in touch with our experts!
Django alone does not support multi-tenancy. It can howere be implemented using ‘tenant’ application through PostgreSQL schemas. Let’s look further into how to enable/install multitenency in Django
