J'ai un utilisateur nommé mi_abc à Oracle 11G. L'utilisateur n'a pas de table dans la base de données mais a accès à toutes les tables d'un autre schéma SCH_ABC. Lorsque j'exécute une requête de sélection normale de SQLDEveloper sur le schéma SCH_ABC de MI_ABC, cela fonctionne parfaitement bien, mais lorsque j'utilise django, je reçois toujours l'erreur: -
J'ai essayé de définir le db_table = sch_abc.tablename et définissez simplement db_table = natal, mais les deux me donne la même erreur. Tout indice comment résoudre ce problème? P> TRACE: - P> django.db.utils.databasError: ora -00942: table ou affichage n'existe pas code> p> Traceback (most recent call last):
File "C:\xxx\xxx\xxx\xxx\xxx\xxx\xxxx\lib\site-packages\django\core\handlers\exception.py", line 41, in inner
response = get_response(request)
File "C:\xxx\xxx\xxxx\xxxx\xxxx\Python\Python37\lib\site-packages\django\utils\deprecation.py", line 142, in __call__
response = self.process_response(request, response)
File "C:\xxxx\xxxx\xxx\xxx\xxx\Python\Python37\lib\site-packages\django\contrib\sessions\middleware.py", line 58, in process_response
request.session.save()
File "C:\xxx\xxxx\xxxx\xxxx\xxxxx\Python\Python37\lib\site-packages\django\contrib\sessions\backends\db.py", line 81, in save
return self.create()
File "C:\xxxx\xxxxx\xxxx\xxxx\xxxxx\Python\Python37\lib\site-packages\django\contrib\sessions\backends\db.py", line 50, in create
self._session_key = self._get_new_session_key()
File "C:\xxxx\xxxxx\xxxxx\xxxxx\xxxx\Python\Python37\lib\site-packages\django\contrib\sessions\backends\base.py", line 164, in _get_new_session_key
if not self.exists(session_key):
File "C:\xxx\xxx\xxx\xxx\xxx\Python\Python37\lib\site-packages\django\contrib\sessions\backends\db.py", line 46, in exists
return self.model.objects.filter(session_key=session_key).exists()
File "C:\xxx\xxx\xxx\xxx\xxx\Python\Python37\lib\site-packages\django\db\models\query.py", line 673, in exists
return self.query.has_results(using=self.db)
File "C:\xxx\xxx\xxx\xxx\xxx\Python\Python37\lib\site-packages\django\db\models\sql\query.py", line 517, in has_results
return compiler.has_results()
File "C:\xxx\xxx\xxx\xxx\xxx\Python\Python37\lib\site-packages\django\db\models\sql\compiler.py", line 858, in has_results
return bool(self.execute_sql(SINGLE))
File "C:\xxx\xxx\xxx\xxx\xxx\Python\Python37\lib\site-packages\django\db\models\sql\compiler.py", line 899, in execute_sql
raise original_exception
File "C:\xxx\xxx\xxx\xxx\xxx\Python\Python37\lib\site-packages\django\db\models\sql\compiler.py", line 889, in execute_sql
cursor.execute(sql, params)
File "C:\xxx\xxx\xxx\xxx\xxx\Python\Python37\lib\site-packages\django\db\backends\utils.py", line 79, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "C:\xxx\xxx\xxx\xxx\xxx\Python\Python37\lib\site-packages\django\db\backends\utils.py", line 64, in execute
return self.cursor.execute(sql, params)
File "C:\xxx\xxx\xxx\xxx\xxx\Python\Python37\lib\site-packages\django\db\utils.py", line 94, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "C:\xxx\xxx\xxx\xxx\xxx\Python\Python37\lib\site-packages\django\utils\six.py", line 685, in reraise
raise value.with_traceback(tb)
File "C:\xxx\xxx\xxx\xxx\xxx\Python\Python37\lib\site-packages\django\db\backends\utils.py", line 64, in execute
return self.cursor.execute(sql, params)
File "C:\xxx\xxx\xxx\xxx\xxx\Python\Python37\lib\site-packages\django\db\backends\oracle\base.py", line 497, in execute
return self.cursor.execute(query, self._param_generator(params))
django.db.utils.DatabaseError: ORA-00942: table or view does not exist
3 Réponses :
Ceci n'est nullement pris en charge officiellement, mais cela fonctionne dans Postgres:
class Meta:
db_table = '"SCHEMA"."TABLE_NAME"'
@Kchow, je suppose qu'il y a une faute de frappe dans la réponse. '\ "schéma \". \ "Table \"' fonctionne bien dans mes projets où j'utilise Oracle.
Y a-t-il un paramètre supplémentaire que je dois ajouter dans les paramètres de paramètres.py?
@borut Ma solution fonctionne avec PostgreSQL, comme indiqué dans la réponse. @Kchow ce que vous aurez besoin de faire est d'imprimer la requête réelle étant générée; Je l'ai fait en utilisant la fonction EMBLY () d'IPYTHON pour déposer au milieu du code à partir de RunServer avant que l'erreur soit expulsée et l'imprimait. J'ai ensuite modifié en conséquence jusqu'à ce que le SQL généré était valide. J'espère que ça aide!
Je pense que le problème est avec la table Django_Session. Mes modèles.py a été codé lorsque j'utilisais directement les informations d'identification du schéma. Et migrer a automatiquement créé les autres tableaux requis pour la manipulation d'authentification et de session. Mais depuis que j'ai changé les informations d'identification pour utiliser un autre ID de service (Détails des utilisateurs), est-ce que l'application ne trouve pas Django-session?
Parce que les classes comme Django_Session, AUTU_USER, etc. ne sont pas présentes dans les modèles.py, elles ont plutôt été créées directement à partir de l'application elle-même.
Vous pouvez définir le schéma requis avant d'exécuter la commande. puis revenir au schéma public une fois que le requérant est traité.
Je reçois l'erreur AttributeError: l'objet "BasewareWrapper" n'a aucun attribut 'Set'. J'ai ajouté vos lignes dans mon fichier modèles.pypy. J'utilise django 1.11.18.
Eh bien, j'ai résolu le problème et laissez-moi vous dire qu'il n'y a pas de bonne manière de le faire à Django. Le problème de ma demande était que j'utilisais les fonctionnalités d'authentification de Django et de la manutention de la session. Toutes ces tables sont créées par Django directement sur la migration initiale. Donc, il n'y a pas d'existence d'eux dans le fichier Modèles.py que vous pouvez simplement ajouter le nom du schéma et demander à votre application de vous connecter au tableau de ce schéma.
Ce que j'ai fini par faire est, j'ai créé des synonymes privés vers toutes les tables de l'autre schéma qui contenait réellement ces tables. Si vous faites cela, vous n'avez rien à changer dans votre code Django. Votre application fonctionnera simplement car Oracle fera le saleté de la connexion à la table appropriée. Vous allez simplement appeler la table dans votre application comme si c'était le vôtre. De cette façon, lorsque Django cherche des tables telles que Django_Session, Auth_User, etc., il s'agit simplement de la question comme si elle le fait toujours et Oracle la redirige vers les tables réelles présentes dans un autre schéma.
J'espère que cela aide les personnes qui font face à cette question à l'avenir.