Produits Entr'ouvert » Passerelle

Pourquoi ne pas utiliser l'attribut _meta des modèles pour trouver ces champs (ça t'aurait éviter la partie relou) ?

https://docs.djangoproject.com/fr/1.11/ref/models/meta/

Je suis en train de bosser dessus.
Valentin m'a filé le patch avec son idée, qui ne sera pas forcément la mienne.

Benjamin Dauvergne a écrit :

Pourquoi ne pas utiliser l'attribut _meta des modèles pour trouver ces champs (ça t'aurait éviter la partie relou) ?

https://docs.djangoproject.com/fr/1.11/ref/models/meta/

Je ne connaissais pas, merci pour la doc (même si en l’occurrence on peut trouver des avantages à avoir l'info en statique, restriction explicite aux seuls champs potentiellement buggés, moins de risque de comportement inattendu, rapidité, etc).

Sur le fond tout me paraît bien, sur la forme les imports ne sont pas dans le bon ordre et il y a trop de lignes blanches.

Idée d'amélioration, ça serait bien que la migration (dans utils/db.py), qui fait la même chose que la commande, utilise aussi le même code (notamment le check du db_type avant la conversion était présent, puis a été retiré car buggé, c'est l'occasion de le remettre). Donc juste copier coller du code de la commande vers la migration.

Serghei Mihai a écrit :

A mon avis ça ne sert à rien de copier/coller le code de vérification du type de la colonne car:
[...]
passe même si la colonne a le bon type.

Ainsi on tape une seule requete par champ lors des migrations au lieu de, potentiellement, deux.

OK mais mon problème c'est plutôt de rendre clair le fait que les deux font la même chose, le code est quand même sacrément différent actuellement. Notamment la boucle for que la commande a en plus, on se demande bien pourquoi il y en a besoin.
Et en me posant cette question je me rends compte qu'il n'y en a pas besoin :

'SELECT table_schema, data_type FROM information_schema.columns WHERE table_name=%s AND column_name=%s'

'SELECT data_type FROM information_schema.columns WHERE table_name=%s AND column_name=%s AND table_schema=%s' % (table_schema=connection.schema_name, ...)

Imports, etc corrigés.

Je ne sais pas comment tu classes les imports, pour moi ça doit ressembler à

import pytest

from django.core.files import File
from django.core.management import call_command
from django.db import connection
from django.utils.six import BytesIO

from passerelle.apps.csvdatasource.models import CsvDataSource
from passerelle.contrib.teamnet_axel.models import TeamnetAxel

Valentin Deniaud a écrit :

Et en me posant cette question je me rends compte qu'il n'y en a pas besoin :
[...]
pourrait être
SELECT data_type FROM information_schema.columns WHERE table_name=%s AND column_name=%s AND table_schema=%s' % (table_schema=connection.schema_name, ...)

Dans ce contexte connection.schema_name n'existe pas. D'ou le SELECT table_schema, data_type pour avoir le schema et le type de la colonne et ceci sans avoir à vérifier si on est en contexte multitenant ou pas.

OK je comprends, la commande n'est pas faite pour marcher avec tenant_command. Je sais pas si ça passe, toutes les commandes que j'ai croisées se lancent avec tenant_command, pour moi la bonne approche c'est celle-ci en exploitant connection.schema_name.
Je vais laisser quelqu'un d'autre valider :/

Elle fonctionne avec tenant_command aussi. Et comme toi au début je ne réflechissais que multitenant (connection.get_tenant().schema_name dans le premier patch brouillon joint au ticket).
Mais la commande doit pouvoir s'éxecuter aussi sans être en multitenant.