{
    "info": {
        "author": "Bernardo Ojengwa",
        "author_email": "bernardojengwa@gmail.com",
        "bugtrack_url": null,
        "classifiers": [
            "Framework :: Django",
            "License :: OSI Approved :: MIT License",
            "Programming Language :: Python"
        ],
        "description": "django-tenant-schemas\n=====================\n\n|PyPi version| |PyPi downloads|\n\nThis application enables `django`_ powered websites to have multiple\ntenants via `PostgreSQL schemas`_. A vital feature for every\nSoftware-as-a-Service website.\n\nDjango provides currently no simple way to support multiple tenants\nusing the same project instance, even when only the data is different.\nBecause we don\u2019t want you running many copies of your project, you\u2019ll be\nable to have:\n\n-  Multiple customers running on the same instance\n-  Shared and Tenant-Specific data\n-  Tenant View-Routing\n\nWhat are schemas\n----------------\n\nA schema can be seen as a directory in an operating system, each\ndirectory (schema) with it\u2019s own set of files (tables and objects). This\nallows the same table name and objects to be used in different schemas\nwithout conflict. For an accurate description on schemas, see\n`PostgreSQL\u2019s official documentation on schemas`_.\n\nWhy schemas\n-----------\n\nThere are typically three solutions for solving the multitenancy\nproblem.\n\n1. Isolated Approach: Separate Databases. Each tenant has it\u2019s own\n   database.\n\n2. Semi Isolated Approach: Shared Database, Separate Schemas. One\n   database for all tenants, but one schema per tenant.\n\n3. Shared Approach: Shared Database, Shared Schema. All tenants share\n   the same database and schema. There is a main tenant-table, where all\n   other tables have a foreign key pointing to.\n\nThis application implements the second approach, which in our opinion,\nrepresents the ideal compromise between simplicity and performance.\n\n-  Simplicity: barely make any changes to your current code to support\n   multitenancy. Plus, you only manage one database.\n-  Performance: make use of shared connections, buffers and memory.\n\nEach solution has it\u2019s up and down sides, for a more in-depth\ndiscussion, see Microsoft\u2019s excellent article on `Multi-Tenant Data\nArchitecture`_.\n\nHow it works\n------------\n\nTenants are identified via their host name (i.e tenant.domain.com). This\ninformation is stored on a table on the ``public`` schema. Whenever a\nrequest is made, the host name is used to match a tenant in the\ndatabase. If there\u2019s a match, the search path is updated to use this\ntenant\u2019s schema. So from now on all queries will take place at the\ntenant\u2019s schema. For example, suppose you have a tenant ``customer`` at\nhttp://customer.example.com. Any request incoming at\n``customer.example.com`` will automatically use ``customer``\\ \u2019s schema\nand make the tenant available at the request. If no tenant is found, a\n404 error is raised. This also means you should have a tenant for your\nmain domain, typically using the ``public`` schema. For more information\nplease read the `setup`_ section.\n\nWhat can this app do?\n---------------------\n\nAs many tenants as you want\n~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nEach tenant has its data on a specific schema. Use a single project\ninstance to serve as many as you want.\n\nTenant-specific and shared apps\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nTenant-specific apps do not share their data between tenants, but you\ncan also have shared apps where the information is always available and\nshared between all.\n\nTenant View-Routing\n~~~~~~~~~~~~~~~~~~~\n\nYou can have different views for ``http://customer.example.com/`` and\n``http://example.com/``, even though Django only uses the string after\nthe host name to identify which view to serve.\n\nMagic\n~~~~~\n\nEveryone loves magic! You\u2019ll be able to have all this barely having to\nchange your code!\n\nSetup & Documentation\n---------------------\n\n**This is just a short setup guide**, it is **strongly** recommended\nthat you read the complete version at\n`django-tenant-schemas.readthedocs.org`_.\n\nYour ``DATABASE_ENGINE`` setting needs to be changed to\n\n.. code-block:: python\n\n    DATABASES = {\n        'default': {\n            'ENGINE': 'tenant_schemas.postgresql_backend',\n            # ..\n        }\n    }    \n\nAdd the middleware ``tenant_schemas.middleware.TenantMiddleware`` to the\ntop of ``MIDDLEWARE_CLASSES``, so that each request can be set to use\nthe correct schema.\n\n.. code-block:: python\n\n    MIDDLEWARE_CLASSES = (\n        'tenant_schemas.middleware.TenantMiddleware',\n        #...\n    )\n    \nAdd ``tenant_schemas.routers.TenantSyncRouter`` to your `DATABASE_ROUTERS` \nsetting, so that the correct apps can be synced, depending on what's \nbeing synced (shared or tenant).\n\n.. code-block:: python\n\n    DATABASE_ROUTERS = (\n        'tenant_schemas.routers.TenantSyncRouter',\n    )\n\nAdd ``tenant_schemas`` to your ``INSTALLED_APPS``.\n\nCreate your tenant model\n~~~~~~~~~~~~~~~~~~~~~~~~\n\n.. code-block:: python\n\n    from django.db import models\n    from tenant_schemas.models import TenantMixin\n\n    class Client(TenantMixin):\n        name = models.CharField(max_length=100)\n        paid_until =  models.DateField()\n        on_trial = models.BooleanField()\n        created_on = models.DateField(auto_now_add=True)\n\nDefine on ``settings.py`` which model is your tenant model. Assuming you\ncreated ``Client`` inside an app named ``customers``, your\n``TENANT_MODEL`` should look like this:\n\n.. code-block:: python\n\n    TENANT_MODEL = \"customers.Client\" # app.Model\n\nNow run ``migrate_schemas`` (``sync_schemas`` if you're on Django 1.6 and older), \nthis will sync your apps to the ``public`` schema.\n\n::\n\n    python manage.py migrate_schemas --shared\n\nCreate your tenants just like a normal django model. Calling ``save``\nwill automatically create and sync/migrate the schema.\n\n.. code-block:: python\n\n    from customers.models import Client\n\n    # create your public tenant\n    tenant = Client(domain_url='tenant.my-domain.com',\n                    schema_name='tenant1',\n                    name='My First Tenant',\n                    paid_until='2014-12-05',\n                    on_trial=True)\n    tenant.save()\n\nAny request made to ``tenant.my-domain.com`` will now automatically set\nyour PostgreSQL\u2019s ``search_path`` to ``tenant1`` and ``public``, making\nshared apps available too. This means that any call to the methods\n``filter``, ``get``, ``save``, ``delete`` or any other function\ninvolving a database connection will now be done at the tenant\u2019s schema,\nso you shouldn\u2019t need to change anything at your views.\n\nYou\u2019re all set, but we have left key details outside of this short\ntutorial, such as creating the public tenant and configuring shared and\ntenant specific apps. Complete instructions can be found at\n`django-tenant-schemas.readthedocs.org`_.\n\n\n\n.. _django: https://www.djangoproject.com/\n.. _PostgreSQL schemas: http://www.postgresql.org/docs/9.1/static/ddl-schemas.html\n.. _PostgreSQL\u2019s official documentation on schemas: http://www.postgresql.org/docs/9.1/static/ddl-schemas.html\n.. _Multi-Tenant Data Architecture: http://msdn.microsoft.com/en-us/library/aa479086.aspx\n\n.. |PyPi version| image:: https://img.shields.io/pypi/v/django-tenant-schemas.svg\n   :target: https://pypi.python.org/pypi/django-tenant-schemas\n.. |PyPi downloads| image:: https://img.shields.io/pypi/dm/django-tenant-schemas.svg\n   :target: https://pypi.python.org/pypi/django-tenant-schemas\n.. _setup: https://django-tenant-schemas.readthedocs.org/en/latest/install.html\n.. _django-tenant-schemas.readthedocs.org: https://django-tenant-schemas.readthedocs.org/en/latest/",
        "description_content_type": null,
        "docs_url": null,
        "download_url": "UNKNOWN",
        "downloads": {
            "last_day": -1,
            "last_month": -1,
            "last_week": -1
        },
        "home_page": "https://github.com/ojengwa/django-multitenants.git",
        "keywords": null,
        "license": "MIT",
        "maintainer": null,
        "maintainer_email": null,
        "name": "django-multitenants",
        "package_url": "https://pypi.org/project/django-multitenants/",
        "platform": "UNKNOWN",
        "project_url": "https://pypi.org/project/django-multitenants/",
        "project_urls": {
            "Download": "UNKNOWN",
            "Homepage": "https://github.com/ojengwa/django-multitenants.git"
        },
        "release_url": "https://pypi.org/project/django-multitenants/1.0.0/",
        "requires_dist": null,
        "requires_python": null,
        "summary": "Tenant support for Django using PostgreSQL schemas. Supports url patterns as well as sub-domains. Inspired by django-tenant-schemas.",
        "version": "1.0.0"
    },
    "last_serial": 2008982,
    "releases": {
        "1.0.0": []
    },
    "urls": []
}