Import - nouveaux identifiants sans millésime

[MaelREBOUX]

Bonjour,

Actuellement, les identifiants de quasiment tous les objets (commue, parcelle, propriétaire, pev, etc, etc) comportent au début le millésime sous la forme d'une année. on se retrouve donc avec des identifiants du genre : 20183500010000A0002. Or : cet identifiant parcellaire n'est pas l'identifiant officiel fourni par la DGFiP. Celui-ci est : 3500010000A0002. On peut multiplier sur quasiment tous les objets.

Selon nous, c'est l'attribut lot qui doit permettre de faire cette gestion de données en double millésime dans une base de données.

Nous allons proposer des modifications dans le module d'import afin de faire disparaître cette info de millésime de tous les identifiants DGFiP.

@EtienneRouvin @landryb @pierrejego @mdouchin Merci de nous faire part de vos commentaires ou réticences éventuelles ;)

[mdouchin]

Je suis d'accord avec le principe. Ce ajout de l'année est issu des scripts SQL OpenCadastre initiaux, que j'ai depuis beaucoup fait évoluer.

Merci pour ce travail

[landryb]

De toute façon on utilise un schéma de bdd distinct par millésime, non ? :)

[pierrejego]

Ou si j'ai bien compris on ne garde pas les millésimes différents :)

Si fonctionnellement ça va à tout le monde, je pense que ça peut alléger un petit peu la base et les jointures pour Cadastrapp, donc je suis pour aussi. C'est d'ailleurs comme ça dans le modèle Arcopole aussi.

[MaelREBOUX]

@landryb : perso oui c'est ce que je ferai mais d'autres ont pensé ça différemment visiblement et ce serait compliqué et/ou mal venu de tirer un trait sur ça amha. Est-ce qu'il faudrait faire un peu de "bruit" / promotion sur cette évolution pour voir si ça réagit ?

@pierrejego oui je me souviens de jointure un peu lourdingues ;)

[landryb]

Est-ce qu'il faudrait faire un peu de "bruit" / promotion sur cette évolution pour voir si ça réagit ?

personne ne réagira jamais tant que ca n'arrivera pas en prod et que les gens s'en rendront compte. C'est le réalisme qui parle :)

[EtienneRouvin]

PR 176 poussée.

[MaelREBOUX]

pour info sur la méthodologie : @EtienneRouvin a fait la modif puis importer des données et on est allé voir à la main sur les 3/4 des tables les plus importants qui contiennent les données / identifiants. Genre : compte communal, code de parcelle, invariant, etc.

Tout OK pour le moment. Là on va faire un import cadastrapp mais à ce stade on voit pas ce qui pourrait coincer.

[EtienneRouvin]

Le code a été mis à jour et les conflits ont été résolus @rldhont

Merci ! :)

[MaelREBOUX]

@EtienneRouvin tu remercieras après le merge de la PR ;)

A moins qu'il y ait un souci avec cette grosse évolution @rldhont ?

[MaelREBOUX]

Résolu