Import générique - Algorithme catch.csv
Bonjour Vincent, Voilà comment l'import du fichier catch.csv est réalisé : Pour chaque opération : - regroupement des lignes du fichier à partir du taxon + vrac / hors vrac ; - les lignes ayant le même taxon sont regroupées en créant des lots fils par catégorie ; - *_Lot_Id sert à faire le lien avec les observations individuelles. - Les numéros d'ordres sont tous réécrits (sans doute pour garantir qu'ils soient tous uniques, car cela a été fait avant la correction du bug sur les rank order). Donc dans ton cas, ton traitement sur les Lot_Id est nécessaire en cas d'observations individuelles, les identifiants doivent être cohérents entre les deux fichiers. Le traitement n'est pas nécessaire dans le cas contraire. Au niveau de l'ordre, il est fait sur l'ordre des identifiants des taxons. Nous allions faire une release pour la doc aujourd'hui, nous pouvons encore changer l'ordre en conservant l'ordre d'apparition des taxons dans le fichier. A toi de nous dire ce que tu préfères, nous ferons la livraison dans la foulée. Est-ce que cela te convient ? N'hésite pas à nous rappeler si tu as des questions. Jean
Bonjour, Le 04/10/2016 à 15:18, Jean Couteau a écrit :
Bonjour Vincent,
Voilà comment l'import du fichier catch.csv est réalisé :
Pour chaque opération : - regroupement des lignes du fichier à partir du taxon + vrac / hors vrac ; - les lignes ayant le même taxon sont regroupées en créant des lots fils par catégorie ; - *_Lot_Id sert à faire le lien avec les observations individuelles. vu - Les numéros d'ordres sont tous réécrits (sans doute pour garantir qu'ils soient tous uniques, car cela a été fait avant la correction du bug sur les rank order). Donc on a une colonne à remplissage obligatoire non prise en compte à l'import !!!
Donc dans ton cas, ton traitement sur les Lot_Id est nécessaire en cas d'observations individuelles, les identifiants doivent être cohérents entre les deux fichiers. Le traitement n'est pas nécessaire dans le cas contraire. Donc (dans le cas où je n'ai pas d'observation individuelles) si je laisse vide V_HV_Lot_Id, Class_Tri_Lot_Id et Sexe_Lot_Id tout se passe bien ? J'ai un gros doute là dessus car sur un exemple simple, les lots ne sont importés que si je renseigne ces colonnes Le comportement est il le même si on importe dans une base vierge ou si on importe en écrasant un existant ?
Au niveau de l'ordre, il est fait sur l'ordre des identifiants des taxons. Nous allions faire une release pour la doc aujourd'hui, nous pouvons encore changer l'ordre en conservant l'ordre d'apparition des taxons dans le fichier. A toi de nous dire ce que tu préfères, nous ferons la livraison dans la foulée. Si cette colonne est obligatoirement à renseigner à l'import alors il faut l'exploiter et faire que le résultat de l'import respecte les info de cette colonne Num_Ordre_V_HV_H2. Mais il y a aussi d'autre colonnes Nul_Ordre_..._H2 pour Class_Tri, Sexe et Taille. Quid du comportement de l'import sur ces colonnes ?
A+ Vincent
Est-ce que cela te convient ? N'hésite pas à nous rappeler si tu as des questions.
Jean _______________________________________________ Tutti-devel mailing list Tutti-devel@list.forge.codelutin.com http://list.forge.codelutin.com/cgi-bin/mailman/listinfo/tutti-devel
-- Vincent BADTS Responsable qualité du SIH (Système d'Informations Halieutiques) IFREMER centre Atlantique Unité EMH (Ecologie et Modèles pour l'Halieutique) Tél : 33 2 40 37 40 53 (interne : 80 53) Fax : 33 2 40 37 40 38 www.ifremer.fr
Bonjour, Je viens de re-tester, l'importation ne se passe bien que si j'ai des V_HV_Lot_Id, Class_tri_Lot_Id et Sexe_Lot_Id (la table des observations individuelles étant vide dans ce test) Sans Lot_Id il n'importe que une ligne et c'est l'espèce avec le plus petit Code_Taxon présent dans la table catch Dans l'attente Vincent Le 05/10/2016 à 09:29, Vincent BADTS a écrit :
Bonjour,
Le 04/10/2016 à 15:18, Jean Couteau a écrit :
Bonjour Vincent,
Voilà comment l'import du fichier catch.csv est réalisé :
Pour chaque opération : - regroupement des lignes du fichier à partir du taxon + vrac / hors vrac ; - les lignes ayant le même taxon sont regroupées en créant des lots fils par catégorie ; - *_Lot_Id sert à faire le lien avec les observations individuelles. vu - Les numéros d'ordres sont tous réécrits (sans doute pour garantir qu'ils soient tous uniques, car cela a été fait avant la correction du bug sur les rank order). Donc on a une colonne à remplissage obligatoire non prise en compte à l'import !!! Donc dans ton cas, ton traitement sur les Lot_Id est nécessaire en cas d'observations individuelles, les identifiants doivent être cohérents entre les deux fichiers. Le traitement n'est pas nécessaire dans le cas contraire. Donc (dans le cas où je n'ai pas d'observation individuelles) si je laisse vide V_HV_Lot_Id, Class_Tri_Lot_Id et Sexe_Lot_Id tout se passe bien ? J'ai un gros doute là dessus car sur un exemple simple, les lots ne sont importés que si je renseigne ces colonnes Le comportement est il le même si on importe dans une base vierge ou si on importe en écrasant un existant ? Au niveau de l'ordre, il est fait sur l'ordre des identifiants des taxons. Nous allions faire une release pour la doc aujourd'hui, nous pouvons encore changer l'ordre en conservant l'ordre d'apparition des taxons dans le fichier. A toi de nous dire ce que tu préfères, nous ferons la livraison dans la foulée. Si cette colonne est obligatoirement à renseigner à l'import alors il faut l'exploiter et faire que le résultat de l'import respecte les info de cette colonne Num_Ordre_V_HV_H2. Mais il y a aussi d'autre
colonnes Nul_Ordre_..._H2 pour Class_Tri, Sexe et Taille. Quid du comportement de l'import sur ces colonnes ?
A+
Vincent
Est-ce que cela te convient ? N'hésite pas à nous rappeler si tu as des questions.
Jean _______________________________________________ Tutti-devel mailing list Tutti-devel@list.forge.codelutin.com http://list.forge.codelutin.com/cgi-bin/mailman/listinfo/tutti-devel
-- Vincent BADTS Responsable qualité du SIH (Système d'Informations Halieutiques)
IFREMER centre Atlantique Unité EMH (Ecologie et Modèles pour l'Halieutique)
Tél : 33 2 40 37 40 53 (interne : 80 53) Fax : 33 2 40 37 40 38
www.ifremer.fr
-- Vincent BADTS Responsable qualité du SIH (Système d'Informations Halieutiques) IFREMER centre Atlantique Unité EMH (Ecologie et Modèles pour l'Halieutique) Tél : 33 2 40 37 40 53 (interne : 80 53) Fax : 33 2 40 37 40 38 www.ifremer.fr
On Thu, 6 Oct 2016 14:27:04 +0200 Vincent BADTS <Vincent.Badts@ifremer.fr> wrote:
Bonjour,
Je viens de re-tester, l'importation ne se passe bien que si j'ai des V_HV_Lot_Id, Class_tri_Lot_Id et Sexe_Lot_Id (la table des observations individuelles étant vide dans ce test)
Ces informations sont obligatoires (toujours obligatoire) mais réellement utilisée que pour faire le lien avec les autres fichiers d'import. Si ces autres fichiers ne sont pas pertinent les Lot_Id n'ont que peu d'importance mais reste obligatoire. Lors de l'import d'un trait existant (même id), celui-ci est supprimé de la base avant l'import. -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
On Wed, 5 Oct 2016 09:29:57 +0200 Vincent BADTS <Vincent.Badts@ifremer.fr> wrote:
Au niveau de l'ordre, il est fait sur l'ordre des identifiants des taxons. Nous allions faire une release pour la doc aujourd'hui, nous pouvons encore changer l'ordre en conservant l'ordre d'apparition des taxons dans le fichier. A toi de nous dire ce que tu préfères, nous ferons la livraison dans la foulée. Si cette colonne est obligatoirement à renseigner à l'import alors il faut l'exploiter et faire que le résultat de l'import respecte les info de cette colonne Num_Ordre_V_HV_H2. Mais il y a aussi d'autre
colonnes Nul_Ordre_..._H2 pour Class_Tri, Sexe et Taille. Quid du comportement de l'import sur ces colonnes ?
Ces colonnes sont obligatoires mais pas prises en compte lors de l'import. Pourquoi ? je ne sais pas, il faudrait voir s'il n'y a pas eu une discussion lors d'une réunion la dessus, et surtout la recette a été faite sur cette implantation sans qu'il n'y ait de retour. Changer l'implantation n'est pas anodin, il faut environ 2 jours de développement pour prendre en compte les numéros d'ordre plutôt que de les recréer. Si on voulait les utiliser, plutôt que de les réécrire lors de l'import, il faudrait qu'ils soient tous cohérents, c'est à dire que - Num_Ordre_V_HV_H2 - Num_Ordre_Sexe_H2 - Num_Ordre_Taille_H2 - ... devraient être cohérents les uns avec les autres, ce qui me semble compliqué à la main. Mieux vaut mettre les lignes dans le bon ordre et laisser tutti générer les rank order Donc pour moi le mieux est de garder l'ordre du fichier et non pas utiliser les rank order. Pour cela, il faut modifier l'implantation pour que l'ordre ne soit pas celui des taxons mais bien celui du fichier et rendre les colonnes Num_Ordre_* optionnelles Si tu donnes ton accord pour ça, on peut le mettre dans la prochaine release qui met à jour la documentation HTML. Par contre, il faut que tu nous fournisses un de tes fichiers pour tester. -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
Bonjour, Est il possible d'avoir une analyse des tickets de la 4.6.1 pour savoir ceux qui sont sous garantie et les autres Merci Vincent
Bonjour, Le Mon, 10 Oct 2016 09:24:40 +0200, Vincent BADTS <Vincent.Badts@ifremer.fr> a écrit :
Est il possible d'avoir une analyse des tickets de la 4.6.1 pour savoir ceux qui sont sous garantie et les autres
Vincent, voici une analyse ticket par ticket sur l'état garantie/hors garantie : #8522 : Comme précisé par Benjamin sur le ticket, les restrictions actuelles ont été ajoutées en janvier 2014. Cela ne relève pas de la garantie. #8567, #8590, #8592 : La dernière évolution sur l'import générique date de janvier 2016. Ces tickets ne relèvent pas de la garantie. #8561 : Les derniers développements concernant la validation des données datent de 2015. Ce ticket ne relève donc pas de la garantie. #8569 : Les derniers développements concernant les espèces temporaires datent de 2015. Ce ticket ne relève donc pas de la garantie. En fonction de l'urgence de chaque ticket, nous pouvons effectuer une estimation (je pense notamment aux tickets #8569, #8592 et #8590 qui sont en priorité haute, urgente et immédiate). S'il n'y a pas urgence, les tickets peuvent faire une excellente entrée en matière pour le prestataire qui réalisera la maintenance à partir de janvier. Nous restons à ta disposition. Bonne soirée. Jean
c'est regrettable d'avoir du relancer sur ces tickets pour m'entendre dire que c'est hors garantie et donc que rien ne va avancer J'ai été habitué à de la très grande réactivité sur ce dossier, pourquoi ce changement ? Vincent Le 10/10/2016 à 18:06, Jean Couteau a écrit :
Bonjour,
Le Mon, 10 Oct 2016 09:24:40 +0200, Vincent BADTS <Vincent.Badts@ifremer.fr> a écrit :
Est il possible d'avoir une analyse des tickets de la 4.6.1 pour savoir ceux qui sont sous garantie et les autres Vincent, voici une analyse ticket par ticket sur l'état garantie/hors garantie :
#8522 : Comme précisé par Benjamin sur le ticket, les restrictions actuelles ont été ajoutées en janvier 2014. Cela ne relève pas de la garantie.
#8567, #8590, #8592 : La dernière évolution sur l'import générique date de janvier 2016. Ces tickets ne relèvent pas de la garantie.
#8561 : Les derniers développements concernant la validation des données datent de 2015. Ce ticket ne relève donc pas de la garantie.
#8569 : Les derniers développements concernant les espèces temporaires datent de 2015. Ce ticket ne relève donc pas de la garantie.
En fonction de l'urgence de chaque ticket, nous pouvons effectuer une estimation (je pense notamment aux tickets #8569, #8592 et #8590 qui sont en priorité haute, urgente et immédiate). S'il n'y a pas urgence, les tickets peuvent faire une excellente entrée en matière pour le prestataire qui réalisera la maintenance à partir de janvier.
Nous restons à ta disposition.
Bonne soirée.
Jean _______________________________________________ Tutti-devel mailing list Tutti-devel@list.forge.codelutin.com http://list.forge.codelutin.com/cgi-bin/mailman/listinfo/tutti-devel
-- Vincent BADTS Responsable qualité du SIH (Système d'Informations Halieutiques) IFREMER centre Atlantique Unité EMH (Ecologie et Modèles pour l'Halieutique) Tél : 33 2 40 37 40 53 (interne : 80 53) Fax : 33 2 40 37 40 38 www.ifremer.fr
Bonjour, Je préfère à ce stade ne rien changer et avoir des spec à jour et précisent sur ce qui est fait à l'import On fera une liste plus complète des améliorations / corrections attendues dans un second temps Merci Vincent Le 06/10/2016 à 18:04, Benjamin POUSSIN a écrit :
On Wed, 5 Oct 2016 09:29:57 +0200 Vincent BADTS <Vincent.Badts@ifremer.fr> wrote:
Au niveau de l'ordre, il est fait sur l'ordre des identifiants des taxons. Nous allions faire une release pour la doc aujourd'hui, nous pouvons encore changer l'ordre en conservant l'ordre d'apparition des taxons dans le fichier. A toi de nous dire ce que tu préfères, nous ferons la livraison dans la foulée. Si cette colonne est obligatoirement à renseigner à l'import alors il faut l'exploiter et faire que le résultat de l'import respecte les info de cette colonne Num_Ordre_V_HV_H2. Mais il y a aussi d'autre
colonnes Nul_Ordre_..._H2 pour Class_Tri, Sexe et Taille. Quid du comportement de l'import sur ces colonnes ? Ces colonnes sont obligatoires mais pas prises en compte lors de l'import.
Pourquoi ? je ne sais pas, il faudrait voir s'il n'y a pas eu une discussion lors d'une réunion la dessus, et surtout la recette a été faite sur cette implantation sans qu'il n'y ait de retour. Changer l'implantation n'est pas anodin, il faut environ 2 jours de développement pour prendre en compte les numéros d'ordre plutôt que de les recréer.
Si on voulait les utiliser, plutôt que de les réécrire lors de l'import, il faudrait qu'ils soient tous cohérents, c'est à dire que - Num_Ordre_V_HV_H2 - Num_Ordre_Sexe_H2 - Num_Ordre_Taille_H2 - ...
devraient être cohérents les uns avec les autres, ce qui me semble compliqué à la main. Mieux vaut mettre les lignes dans le bon ordre et laisser tutti générer les rank order
Donc pour moi le mieux est de garder l'ordre du fichier et non pas utiliser les rank order. Pour cela, il faut modifier l'implantation pour que l'ordre ne soit pas celui des taxons mais bien celui du fichier et rendre les colonnes Num_Ordre_* optionnelles
Si tu donnes ton accord pour ça, on peut le mettre dans la prochaine release qui met à jour la documentation HTML. Par contre, il faut que tu nous fournisses un de tes fichiers pour tester.
-- Vincent BADTS Responsable qualité du SIH (Système d'Informations Halieutiques) IFREMER centre Atlantique Unité EMH (Ecologie et Modèles pour l'Halieutique) Tél : 33 2 40 37 40 53 (interne : 80 53) Fax : 33 2 40 37 40 38 www.ifremer.fr
Bonjour, Le Mon, 10 Oct 2016 09:40:55 +0200, Vincent BADTS <Vincent.Badts@ifremer.fr> a écrit :
Je préfère à ce stade ne rien changer et avoir des spec à jour et précisent sur ce qui est fait à l'import
Ok, donc nous allons préciser les spécifications sur ce point. Nous te ferons valider et ferons la release avec la documentation et les spécifications dans la foulée. Comme ça tout sera en phase. Jean
participants (3)
-
Benjamin POUSSIN -
Jean Couteau -
Vincent BADTS