# Advanced configuration

## Fast dynamic tenant creation

Every time a instance of `settings.TENANTS["default"]["TENANT_MODEL"]` is created, by default, the corresponding schema is created and synchronized automatically. Depending on the number of migrations you already have in place, or the amount of time these could take, or whether you need to pre-populate the newly created schema with fixtures, this process could take a considerable amount of time.

If you need a faster creation of dynamic schemas, you can do so by provisioning a “reference” schema that can cloned into new schemas.

    TENANTS = {
        # ...
        "default": {
            # ...
            "CLONE_REFERENCE": "sample",
        },
    }

Once you have this in your settings, you need to prepare your reference schema with everything a newly created dynamic schema will need. The first step is actually creating and synchronizing the reference schema. After that, you can run any command on it, or edit its tables via `shell`.

    python manage.py createrefschema
    python runschema loaddata tenant_app.products -s sample
    python runschema shell -s sample

The `runschema` command is explained in Running management commands.

You don’t need any extra step. As soon as a reference schema is configured, next time you create an instance of the tenant model, it will clone the reference schema instead of actually creating and synchronizing the schema.

Most importantly, by default, migrations will include the reference schema, so that it is kept up to date for future tenant creation.

Tip

The reference schema will get apps from `settings.TENANTS["default"]["APPS"]` and may look like any other dynamic tenant, but it is considered a static tenant instead, as there is no corresponding database entry for it. It’s a special case of a static tenant, and it cannot be routed.

## Fallback domains

If there is only one domain available, and no possibility to use subdomain routing, the URLs for accessing your different tenants might look like:

    mydomain.com                -> main site
    mydomain.com/customer1      -> customer 1
    mydomain.com/customer2      -> customer 2

In this case, due to the order in which domains are tested, it is not possible to put `mydomain.com` as domain for the main tenant without blocking all dynamic schemas from getting routed. When `django_pgschemas.middleware.TenantMiddleware` is checking which tenant to route from the incoming domain, it checks for static tenants first, then for dynamic tenants. If `mydomain.com` is used for the main tenant (which is static), then URLs like `mydomain.com/customer1/some/url/` will match the main tenant always.

For a case like this, we provide a setting called `FALLBACK_DOMAINS`. If no tenant is found for an incoming combination of domain and subfolder, then, static tenants are checked again for the fallback domains.

Something like this would be the proper configuration for the present case:

    TENANTS = {
        "public": {
            "APPS": [
                "django.contrib.contenttypes",
                "django.contrib.staticfiles",
                # ...
                "django_pgschemas",
                "shared_app",
                # ...
            ],
        },
        "main": {
            "APPS": [
                "django.contrib.auth",
                "django.contrib.sessions",
                # ...
                "main_app",
            ],
            "DOMAINS": [],  # <--- No domain here
            "FALLBACK_DOMAINS": ["mydomain.com"], # <--- This is checked last
            "URLCONF": "main_app.urls",
        },
        "default": {
            "TENANT_MODEL": "shared_app.Client",
            "DOMAIN_MODEL": "shared_app.Domain",
            "APPS": [
                "django.contrib.auth",
                "django.contrib.sessions",
                # ...
                "tenant_app",
                # ...
            ],
            "URLCONF": "tenant_app.urls",
        }
    }

This example assumes that dynamic tenants will get their domains set to `mydomain.com` with a tenant specific subfolder, like `client1` or `client2`.

Here, an incoming request for `mydomain.com/client1/some/url/` will fail for the main tenant, then match against an existing dynamic tenant. On the other hand, an incoming request for `mydomain.com/some/url/` will fail for all static tenants, then fail for all dynamic tenants, and will finally match against the fallback domains of the main tenant.

## Static-only tenants

It’s also possible to have only static tenants. For this, the default key must be omitted:

    TENANTS = {
        "public": {
            "APPS": [
                "django.contrib.contenttypes",
                "django.contrib.staticfiles",
                # ...
                "django_pgschemas",
                "shared_app",
                # ...
            ],
        },
        "www": {
            "APPS": [
                "django.contrib.auth",
                "django.contrib.sessions",
                # ...
                "main_app",
            ],
            "DOMAINS": ["mydomain.com"],
            "URLCONF": "main_app.urls",
        },
        "blog": {
            "APPS": [
                "django.contrib.auth",
                "django.contrib.sessions",
                # ...
                "blog_app",
            ],
            "DOMAINS": ["blog.mydomain.com", "help.mydomain.com"],
            "URLCONF": "blog_app.urls",
        }
    }

In this case, no model is expected to inherit from `TenantMixin` and `DomainMixin`, and no clone reference schema can be created.

## Running management commands

Since all management commands occur outside the request/response cycle, all commands from Django and any other third party apps are executed by default on the public schema. In order to work around this, we provide a `runschema` command that accepts any other command to be run on one or multiple schemas. A concise synopsis of the `runschema` command is as follows:

    usage: manage.py runschema [-s SCHEMAS [SCHEMAS ...]]
                            [-x EXCLUDED_SCHEMAS [EXCLUDED_SCHEMAS ...]]
                            [-as] [-ss] [-ds] [-ts]
                            [--parallel]
                            [--no-create-schemas]
                            [--noinput]
                            command_name

    Wrapper around django commands for use with an individual schema

    positional arguments:
    command_name          The command name you want to run

    optional arguments:

    --noinput, --no-input
                        Tells Django to NOT prompt the user for input of any
                        kind.

    -s SCHEMAS [SCHEMAS ...],
    --schema SCHEMAS [SCHEMAS ...]
                        Schema(s) to execute the current command
    -as, --include-all-schemas
                        Include all schemas when executing the current command
    -ss, --include-static-schemas
                        Include all static schemas when executing the current
                        command
    -ds, --include-dynamic-schemas
                        Include all dynamic schemas when executing the current
                        command
    -ts, --include-tenant-schemas
                        Include all tenant-like schemas when executing the
                        current command
    -x EXCLUDED_SCHEMAS [EXCLUDED_SCHEMAS ...],
    --exclude-schema EXCLUDED_SCHEMAS [EXCLUDED_SCHEMAS ...]
                        Schema(s) to exclude when executing the current
                        command

    --parallel          Run command in parallel mode
    --no-create-schemas
                        Skip automatic creation of non-existing schemas

The `--schema` parameter accepts multiple inputs of different kinds:

- The key of a static tenant or the `schema_name` of a dynamic tenant.

- The prefix of any domain, provided only one corresponding tenant is found.

- The `domain/folder` of a tenant, like `customers.mydomain.com/client1`

The parameters `-as`, `-ss`, `-ds` and `-ts` act as wildcards for including all schemas, static schemas, dynamic schemas and tenant-like schemas, respectively. Tenant-like schemas are dynamic schemas plus the clone reference, if it exists.

It’s possible to exclude schemas via the `-x` parameter. Excluded schemas will take precedence over included ones.

At least one schema is mandatory. If it’s not provided with the command, either explicitly or via wildcard params, it will be asked interactively. One notable exception to this is when the option `--noinput` is passed, in which case the command will fail.

If `--parallel` is passed, the command will be run asynchronously, spawning multiple threads controlled by the setting `PGSCHEMAS_PARALLEL_MAX_PROCESSES`. It defaults to `None`, in which case the number of CPUs will be used.

By default, schemas that do not exist will be created (but not synchronized), except if `--no-create-schemas` is passed.

Full details for this command can be found in runschema.

### Inheritable commands

We also provide some base commands you can inherit, in order to mimic the behavior of `runschema`. By inheriting these you will get the parameters we discussed in the previous section. The base commands provide a `handle_tenant` you must override in order to execute the actions you need on any given tenant.

The base commands are:

    # django_pgschemas.management.commands.__init__.py

    class TenantCommand(WrappedSchemaOption, BaseCommand):
        # ...

        def handle_tenant(self, tenant, *args, **options):
            pass

    class StaticTenantCommand(TenantCommand):
        # ...

    class DynamicTenantCommand(TenantCommand):
        # ...

Attention

Since these commands can work with both static and dynamic tenants, the parameter `tenant` will be an instance of `django_pgschemas.schema.SchemaDescriptor`. Make sure you do the appropriate type checking before accessing the tenant members, as not every tenant will be an instance of `settings.TENANTS["default"]["TENANT_MODEL"]`.