Produits Entr'ouvert » Passerelle

Du coup, nouveaux patchs (rebase et compagnie, ça passe le jenkins sans gueuler)
Le premier reste identique, ne pas charger inutilement les données de la BAN.
Le second est une grosse optimisation de la partie qui charge les données des régions, départements et villes pour ne plus faire de remplacement systématique en base.
Il faudrait encore optimiser le chargement des rues depuis la BAN, mais je pense qu'on peut garder cette optimisation pour un second temps.

Le code de 0002 pourrait être simplifié en faisant quelque chose de la forme :

    keys = {'code': 1}
    attributes = {'a': 1, 'b': 2, 'c': 3}
    try:
        Model.objects.get(**keys, **attributes)
    except Model.DoesNotExist:
        Model.objects.update_or_create(**keys, defaults=attributes)

update_or_create va refaire un select qui a été fait, avant de déterminer s'il vaut mieux faire un insert ou un update (dommage qu'ils ne fassent pas d'upsert)
Certes on va simplifier le code Python, mais on aura SELECT + SELECT FOR UPDATE + INSERT/UPDATE au lieu de SELECT + INSERT/UPDATE.
Vu le volume de mise à jour c'est pas critique, du coup si vous préférez simplifier le python, allons-y gaiement.
Ci-joint un complément écrit avant le commentaire précédent : la même chose pour les données des rues.

Pierre Ducroquet a écrit :

constaté sur des vieux tenants en prod qui ne sont pas maintenus depuis un certain temps...

Heu, c'est-à-dire ? C'est géré par du cron, y'a pas trop de raison... (Je conteste pas l'existence d'un soucis mais je veux le comprendre ;) )

- introduction d'une migration 27 qui passe la colonne ban_id en nullable et remplace les '' par des null
- passage de la migration précédemment ajoutée en 28 (pour l'ajout de la contrainte)

Mais que va-t-il se passer sur les endroits où la migration 27 (actuelle) aurait déjà été jouée ?

mon avis: ne pas mélanger migration de schéma et migration de données dans une même migration django

Lauréline Guerin a écrit :

mon avis: ne pas mélanger migration de schéma et migration de données dans une même migration django

Je confirme que c'est systématiquement un nid à problème, il faut décomposer en plusieurs migrations.

Hum, et si je la passe en atomic=False, ça règle pas les soucis potentiels ? Si vous avez des détails sur les problèmes, je suis preneur d'ailleurs.

Pierre Ducroquet a écrit :

Hum, et si je la passe en atomic=False, ça règle pas les soucis potentiels ? Si vous avez des détails sur les problèmes, je suis preneur d'ailleurs.

En atomic=False chaque opération de la migration s'exécute hors d'une transaction, et non c'est pire, si la migration échoue l'état n'est ni avant, ni après. Le souci vient surtout de migration de donnée qui vont générer de la validation de contrainte déférée (je ne doute pas que d'autres cas soit possible, mais j'ai surtout vu celui-là). Ayant eu le problème sur la suppression d'un champ, j'ai juste passé la validation des contraintes en immédiat¹.

Benjamin Dauvergne a écrit :

Pierre Ducroquet a écrit :

Hum, et si je la passe en atomic=False, ça règle pas les soucis potentiels ? Si vous avez des détails sur les problèmes, je suis preneur d'ailleurs.

En atomic=False chaque opération de la migration s'exécute hors d'une transaction, et non c'est pire, si la migration échoue l'état n'est ni avant, ni après.

Quand chaque étape de la transaction est rejouable ad nauseam, en quoi serait-ce un problème ?

Le souci vient surtout de migration de donnée qui vont générer de la validation de contrainte déférée (je ne doute pas que d'autres cas soit possible, mais j'ai surtout vu celui-là). Ayant eu le problème sur la suppression d'un champ, j'ai juste passé la validation des contraintes en immédiat.

Je vois très bien le SQL qui sera généré ici, et il n'y a aucune raison qu'un tel problème se pose.

Automatic expiration