Development #32685
multitenant: les classes Thread surchargées doivent être chargées le plus tôt possible
0%
Description
Pour éviter à d'autres librairies (exemple, paramiko) d'utiliser les deux il faut charger celles-ci le plus tôt possible, voir #32683.
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Benjamin Dauvergne il y a presque 5 ans
- Lié à Support #32683: sftp: incompatibilité entre paramiko et la surcharge de threading par hobo ajouté
Mis à jour par Benjamin Dauvergne il y a presque 5 ans
- Fichier 0001-multitenant-load-multitenant-thread-classes-early-on.patch 0001-multitenant-load-multitenant-thread-classes-early-on.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Ça devrait faire l'affaire.
Mis à jour par Christophe Siraut il y a presque 5 ans
Pour éviter à d'autres librairies (exemple, paramiko) d'utiliser les deux il faut charger celles-ci le plus tôt possible
les deux quoi? Le code déplacé est identique, j'imagine que l'import en début de apps.py fait la différence.
Mis à jour par Benjamin Dauvergne il y a presque 5 ans
Christophe Siraut a écrit :
Pour éviter à d'autres librairies (exemple, paramiko) d'utiliser les deux il faut charger celles-ci le plus tôt possible
les deux quoi? Le code déplacé est identique, j'imagine que l'import en début de apps.py fait la différence.
Pardon d'utiliser les deux implémentations des threads, le fait est que paramiko est mal écrit, il fait directement appel à Thread.init() au lieu d'utiliser super() et ça casse tout (il appelle TenantAwareThread.__init__() alors que sa classe n'en hérite pas).
À terme il faudrait arrêter avec le monkeypatching et utiliser directement TenantAwareThread quand c'est nécessaire.
Mis à jour par Benjamin Dauvergne il y a presque 5 ans
- Fichier 0001-multitenant-load-multitenant-thread-classes-early-on.patch 0001-multitenant-load-multitenant-thread-classes-early-on.patch ajouté
Typo idiote, 'False' -> False.
Mis à jour par Benjamin Dauvergne il y a presque 5 ans
- Fichier 0001-multitenant-load-multitenant-thread-classes-early-on.patch 0001-multitenant-load-multitenant-thread-classes-early-on.patch ajouté
Maintenant il faut prendre en compte le fait de ne pas tourner dans un environnement multitenant (entre les tests).
Mis à jour par Nicolas Roche il y a presque 5 ans
- Statut changé de Solution proposée à Solution validée
On se place au début des chargements (quand hobo.multitenant est chargé).
comme passerelle.utils.sftp ne sera appelé que par des applications passerelle bien après, ça ira :
hobo/multitenant/_init__.py:_
... threads.install_tenant_aware_threads()
surcharge
/usr/lib/python2.7/threading.py.
Difficile à tester car dans un test on est forcément après AppConfig.ready().
Là on essaye de se placer avant AppConfig.ready() :
avant le chargement de l'ensemble des applications Django, sachant que paramiko est chargé à ce moment.
Le code n'est pas exactement pareil à cause des tests de hobo qui ne tournent pas en multitenant : si le driver de DB n'est pas celui de django-tenant-schemas connection.get_tenant() n'existe pas.
Or en déplaçant l'initialisation plus tôt on constate qu'un truc quelque part charge hobo.multitenant.
Merci pour les explications. Je valide.
Mis à jour par Benjamin Dauvergne il y a presque 5 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 01a24f29a59322c9f1b83e36cdf5f5e20a156e9c
Author: Benjamin Dauvergne <bdauvergne@entrouvert.com>
Date: Mon Apr 29 18:35:57 2019 +0200
multitenant: load multitenant thread classes early on (#32685)
Also do not keep a tenant around if current database wrapper is not
multitenant aware.Mis à jour par Frédéric Péters il y a presque 5 ans
- Statut changé de Résolu (à déployer) à Solution déployée
multitenant: load multitenant thread classes early on (#32685)
Also do not keep a tenant around if current database wrapper is not
multitenant aware.