Applications multi-locataires Django: modification de la connexion à la base de données par demande?

j'ai fait quelque chose de similaire qui est le plus proche du point 1, mais au lieu d'utiliser middleware pour définir une connexion par défaut les routeurs de base de données Django sont utilisés. Cela permet à application logic d'utiliser un certain nombre de bases de données si nécessaire pour chaque requête. C'est à la demande de la logique de choisir une base de données pour chaque requête, et c'est le gros inconvénient de cette approche.

avec cette configuration, toutes les bases de données sont listées dans settings.DATABASES , y compris les bases de données qui peut être partagé entre les clients. Chaque modèle personnalisé est placé dans une application Django qui possède une étiquette app spécifique.

par exemple. La classe suivante définit un modèle qui existe dans toutes les bases de données client.

class MyModel(Model):
    ....
    class Meta:
        app_label = 'customer_records'
        managed = False

un routeur de base de données est placé dans la chaîne settings.DATABASE_ROUTERS pour acheminer la demande de base de données par app_label , quelque chose comme ceci (pas un exemple complet):

class AppLabelRouter(object):
    def get_customer_db(self, model):
        # Route models belonging to 'myapp' to the 'shared_db' database, irrespective
        # of customer.
        if model._meta.app_label == 'myapp':
            return 'shared_db'
        if model._meta.app_label == 'customer_records':
            customer_db = thread_local_data.current_customer_db()
            if customer_db is not None:
                return customer_db

            raise Exception("No customer database selected")
        return None

    def db_for_read(self, model, **hints):
        return self.get_customer_db(model, **hints)

    def db_for_write(self, model, **hints):
        return self.get_customer_db(model, **hints)

La partie spéciale sur ce routeur est l'appel thread_local_data.current_customer_db() . Avant que le routeur soit utilisé, l'appelant/l'application doit avoir configuré la base de données client actuelle dans thread_local_data . Un gestionnaire de contexte Python peut être utilisé à cette fin pour pousser/pop une base de données client actuelle.

avec tout cela configuré, le code d'application ressemble alors à quelque chose comme ceci, où UseCustomerDatabase est un gestionnaire de contexte pour pousser / pop un nom de base de données client actuel dans thread_local_data de sorte que thread_local_data.current_customer_db() retournera le corriger le nom de la base de données lorsque le routeur est éventuellement activé:

class MyView(DetailView):
    def get_object(self):
        db_name = determine_customer_db_to_use(self.request) 
        with UseCustomerDatabase(db_name):
            return MyModel.object.get(pk=1)

c'est déjà une configuration assez complexe. Cela fonctionne, mais je vais essayer de résumer ce que je vois comme avantages et inconvénients:

avantages

• la sélection de la base de données est flexible. Il permet d'utiliser plusieurs bases de données dans une seule requête, les bases de données spécifiques au client et partagées peuvent être utilisées dans une requête.
La sélection de la base de données
• est explicite (on ne sait pas s'il s'agit d'un avantage ou d'un inconvénient). Si vous essayez d'exécuter une requête qui frappe une base de données de client mais l'application n'a pas sélectionné un, une exception se produira indiquant une erreur de programmation.
• L'utilisation d'un routeur de base de données permet à différentes bases de données d'exister sur des hôtes différents, plutôt que de s'appuyer sur une déclaration USE db; qui suppose que toutes les bases de données sont accessibles par une connexion unique.

désavantages

• c'est complexe à configurer, et il y a pas mal de couches impliquées pour le faire fonctionner.
• le besoin et l'utilisation de données locales de thread est obscur.
• vues sont parsemées de code de sélection de base de données. Cela pourrait être résumé en utilisant des vues basées sur la classe pour choisir automatiquement une base de données basée sur les paramètres de la requête dans le même manner comme middleware choisirait une base de données par défaut.
• le gestionnaire de contexte pour choisir une base de données doit être enroulé autour d'un queryset de telle manière que le gestionnaire de contexte est toujours actif lorsque la requête est évaluée.

Suggestions

si vous voulez un accès flexible à la base de données, je vous conseille D'utiliser les routeurs de la base de données de Django. Utilisez Middleware ou une vue Mixin qui s'installe automatiquement une base de données par défaut à utiliser pour la connexion basée sur les paramètres de la requête. Vous pourriez avoir à recourir à thread local database pour stocker la base de données par défaut à utiliser de sorte que lorsque le routeur est frappé, il sait à quelle base de données acheminer. Cela permet à Django d'utiliser ses connexions persistantes existantes à une base de données (qui peut résider sur différents serveurs si désiré), et choisit la base de données à utiliser sur la base du routage mis en place dans la demande.

Cette approche a aussi l'avantage que la base de données pour une requête peut être annulée si nécessaire en utilisant la fonction QuerySet using() pour sélectionner une base de données autre que la valeur par défaut.

vous pouvez créer un middleware simple de votre propre qui a déterminé le nom de la base de données à partir de votre sous-domaine ou autre et puis exécuté un utiliser déclaration sur le curseur de la base de données pour chaque demande. En regardant le code django-tenants-schema, c'est essentiellement ce qu'il fait. Il est sous-classant psycopg2 et émet les postgres équivalents à utiliser, "set search_path XXX". Vous pouvez créer un modèle pour gérer et créer vos locataires trop, mais alors vous seriez en réécriture de la plupart des Django-locataires-schéma.

il ne devrait pas y avoir de pénalité de performance ou de ressources dans MySQL à la commutation du schéma (nom de la base de données). Il s'agit simplement de définir un paramètre de session pour la connexion.