Anomalie #7932 [Référentiel] Erreur Java obtenue en allant dans la configuration
bonjour, je viens de soumettre une anomalie car on obtient une erreur en allant dans la configuration suite à une mise à jour des référentiels. J'ai essayé de voir le problème au niveau des référentiels (à priori navire), mais je ne comprends pas car d'après les requêtes effectuées je n'obtient pas de doublon contrairement à ce que l'erreur indique. A moins qu'il y ait une autre requête que celle en SQL qui est ensuite exécutée et que je ne peux pas analyser. Merci de regarder Christian -- Site Ifremer <http://www.ifremer.fr> Christian BONNET Centre de Brest ZI de la pointe du diable CS 10070 - 29280 Plouzané Informatique et Données Marines Ingénierie des Systèmes d'Information christian.bonnet@ifremer.fr <mailto:christian.bonnet@ifremer.fr> www.ifremer.fr <http://www.ifremer.fr> Tel : +33 (0)2.98.22.46.16 Fax : +33 (0)2.98.22.46.44
On Fri, 22 Jan 2016 12:32:02 +0100 Christian BONNET <Christian.Bonnet@ifremer.fr> wrote:
bonjour,
je viens de soumettre une anomalie car on obtient une erreur en allant dans la configuration suite à une mise à jour des référentiels. J'ai essayé de voir le problème au niveau des référentiels (à priori navire), mais je ne comprends pas car d'après les requêtes effectuées je n'obtient pas de doublon contrairement à ce que l'erreur indique. A moins qu'il y ait une autre requête que celle en SQL qui est ensuite exécutée et que je ne peux pas analyser.
Ok on regarde de quoi il retourne. tony. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: chemit@codelutin.com twitter: https://twitter.com/tchemit
On Fri, 22 Jan 2016 14:47:26 +0100 Tony Chemit <chemit@codelutin.com> wrote:
On Fri, 22 Jan 2016 12:32:02 +0100 Christian BONNET <Christian.Bonnet@ifremer.fr> wrote:
bonjour,
Bonjour, après vérification j'ai trouvé un doublon dans la table VESSEL_FEATURES pour le navire de code '******' avec une date de fin non renseignée. SELECT t.* FROM PUBLIC.VESSEL_FEATURES t WHERE VESSEL_FK='******' donc dans la requête cela remonte deux fois le navire, ce qui provoque ensuite une erreur lorsque que l'on veut produire un dictionnaire indexé par le code du navire. Il faut il me semble produire une nouvelle version du référentiel qui corrige le problème. Je vais compléter le ticket. Je vous ai déjà proposer de faire des vérifications sur les bases de référentiel; je comprends bien que vous ne voulez pas que cela soit fait dans Tutti car ce n'est pas forcement le bon endroit, mais il faudrait AMHA quand même faire ses vérifications. On peut en rediscuter si vous le voulez conjointement avec Benoît. Cordialement, Tony
je viens de soumettre une anomalie car on obtient une erreur en allant dans la configuration suite à une mise à jour des référentiels. J'ai essayé de voir le problème au niveau des référentiels (à priori navire), mais je ne comprends pas car d'après les requêtes effectuées je n'obtient pas de doublon contrairement à ce que l'erreur indique. A moins qu'il y ait une autre requête que celle en SQL qui est ensuite exécutée et que je ne peux pas analyser.
Ok on regarde de quoi il retourne.
tony.
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: chemit@codelutin.com twitter: https://twitter.com/tchemit
bonjour, merci pour le diagnostique. Je vais regarder d'où ça peut venir (on n'a pas le doublon dans le système central, mais il a peut être existé et été corrigé, il faut que je regénère la base locale). On pourrait effectivement faire des tests et des corrections dans Tutti, mais on en a déjà parlé et ça ne serait pas la bonne manière de fonctionner pour plusieurs raisons : * il faudrait faire ces tests sur chaque outil * il faudrait ensuite les maintenir * on ne saurait pas forcément quelle info retenir en cas de doublon * il ne faudrait pas uniquement corriger les données en local, mais remonter l'information pour les corriger en central * ... Donc il est préférable de ne pas implémenter ces tests / corrections dans les outils. Ces cas d'erreur sur les référentiels sont relativement isolés et on est organisé en exploitation pour faire face à ces situations mais ça nécessite juste que les outils fournissent suffisamment d'informations pour pouvoir diagnostiquer l'origine du problème. Il n'est pas gênant que l'utilisateur ait un message Java à l'écran (même si ça peut ne pas paraitre "propre"). Par contre, il faut ensuite que le guichet d'exploitation puisse diagnostiquer l'erreur et la corriger. Ca permet aussi d'enrichir des procédures de contrôle au niveau du système central (plutôt que de les mettre dans chaque outil). Si on doit réfléchir à quelque chose à mettre en place, c'est plus d'avoir une trace pour obtenir la requête qui pose problème sans qu'on soit obligé d'avoir l'environnement de développement et de lancer un debuggage de l'outil. En occurrence, ce qui me gêne ici c'est de ne pas avoir la requête qui pose problème sur vessel_features dans les logs. On aurait pu s'en sortir avec les logs car on y voit le code du navire qui pose problème, mais cette fois pas de chance le code était '******' donc j'ai pensé qu'on n'avait pas l'information. Christian Le 24/01/2016 19:44, Tony Chemit a écrit :
On Fri, 22 Jan 2016 14:47:26 +0100 Tony Chemit <chemit@codelutin.com> wrote:
On Fri, 22 Jan 2016 12:32:02 +0100 Christian BONNET <Christian.Bonnet@ifremer.fr> wrote:
bonjour, Bonjour,
après vérification j'ai trouvé un doublon dans la table VESSEL_FEATURES pour le navire de code '******' avec une date de fin non renseignée.
SELECT t.* FROM PUBLIC.VESSEL_FEATURES t WHERE VESSEL_FK='******'
donc dans la requête cela remonte deux fois le navire, ce qui provoque ensuite une erreur lorsque que l'on veut produire un dictionnaire indexé par le code du navire.
Il faut il me semble produire une nouvelle version du référentiel qui corrige le problème.
Je vais compléter le ticket.
Je vous ai déjà proposer de faire des vérifications sur les bases de référentiel; je comprends bien que vous ne voulez pas que cela soit fait dans Tutti car ce n'est pas forcement le bon endroit, mais il faudrait AMHA quand même faire ses vérifications. On peut en rediscuter si vous le voulez conjointement avec Benoît.
Cordialement, Tony
je viens de soumettre une anomalie car on obtient une erreur en allant dans la configuration suite à une mise à jour des référentiels. J'ai essayé de voir le problème au niveau des référentiels (à priori navire), mais je ne comprends pas car d'après les requêtes effectuées je n'obtient pas de doublon contrairement à ce que l'erreur indique. A moins qu'il y ait une autre requête que celle en SQL qui est ensuite exécutée et que je ne peux pas analyser. Ok on regarde de quoi il retourne.
tony.
-- Site Ifremer <http://www.ifremer.fr> Christian BONNET Centre de Brest ZI de la pointe du diable CS 10070 - 29280 Plouzané Informatique et Données Marines Ingénierie des Systèmes d'Information christian.bonnet@ifremer.fr <mailto:christian.bonnet@ifremer.fr> www.ifremer.fr <http://www.ifremer.fr> Tel : +33 (0)2.98.22.46.16 Fax : +33 (0)2.98.22.46.44
On Mon, 25 Jan 2016 10:13:25 +0100 Christian BONNET <Christian.Bonnet@ifremer.fr> wrote:
bonjour,
merci pour le diagnostique. Je vais regarder d'où ça peut venir (on n'a pas le doublon dans le système central, mais il a peut être existé et été corrigé, il faut que je regénère la base locale).
On pourrait effectivement faire des tests et des corrections dans Tutti, mais on en a déjà parlé et ça ne serait pas la bonne manière de fonctionner pour plusieurs raisons :
Tu n'as pas du bien lire mon propos. Je vous propose d'avoir un outil de diagnostic de votre référentiel totalement indépendant de Tutti, pour que tu puisses exécuter avant de délivrer une nouvelle base de référentiel. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: chemit@codelutin.com twitter: https://twitter.com/tchemit
bonjour, effectivement je n'avais pas compris ça. La complexité de l'exploitation du système halieutique et en particulier du référentiel fait que l'équipe d'exploitation développe elle même ces propres traitements de vérification. Il s'agit généralement de requêtes exécutées directement sur la base par un outil SQL. Le travail est en cours et en consolidation permanente donc l'organisation ne collerait pas avec la réalisation d'un outil comme tu le proposes (car il faudrait le faire évoluer trop souvent). Christian Le 26/01/2016 09:21, Tony Chemit a écrit :
On Mon, 25 Jan 2016 10:13:25 +0100 Christian BONNET <Christian.Bonnet@ifremer.fr> wrote:
bonjour,
merci pour le diagnostique. Je vais regarder d'où ça peut venir (on n'a pas le doublon dans le système central, mais il a peut être existé et été corrigé, il faut que je regénère la base locale).
On pourrait effectivement faire des tests et des corrections dans Tutti, mais on en a déjà parlé et ça ne serait pas la bonne manière de fonctionner pour plusieurs raisons : Tu n'as pas du bien lire mon propos.
Je vous propose d'avoir un outil de diagnostic de votre référentiel totalement indépendant de Tutti, pour que tu puisses exécuter avant de délivrer une nouvelle base de référentiel.
-- Site Ifremer <http://www.ifremer.fr> Christian BONNET Centre de Brest ZI de la pointe du diable CS 10070 - 29280 Plouzané Informatique et Données Marines Ingénierie des Systèmes d'Information christian.bonnet@ifremer.fr <mailto:christian.bonnet@ifremer.fr> www.ifremer.fr <http://www.ifremer.fr> Tel : +33 (0)2.98.22.46.16 Fax : +33 (0)2.98.22.46.44
On Tue, 26 Jan 2016 09:31:25 +0100 Christian BONNET <Christian.Bonnet@ifremer.fr> wrote:
bonjour,
effectivement je n'avais pas compris ça.
La complexité de l'exploitation du système halieutique et en particulier du référentiel fait que l'équipe d'exploitation développe elle même ces propres traitements de vérification. Il s'agit généralement de requêtes exécutées directement sur la base par un outil SQL. Le travail est en cours et en consolidation permanente donc l'organisation ne collerait pas avec la réalisation d'un outil comme tu le proposes (car il faudrait le faire évoluer trop souvent).
Je ne suis pas d'accord avec toi sur ce point. Le fait de se retrouver avec un référentiel incohérent sur une application finale n'est pas normale. Il y a un certain nombre de choses qui ne varieront jamais : * périodes sur les navires cohérentes par exemple. Quoiqu'il en soit, je ne dis ça que pour vous; le temps que je passe à diagnostiquer cela c'est du temps perdu sur le développement client et ce n'est pas moi qui en pâtit. Je ne vais pas batailler avec toi Christian, tout en ne comprenant pas ton point de vue. Oui je sais bien l'exploitation ce n'est pas mon domaine; sauf que tu te retournes vers moi quand ça ne fonctionne pas dans Tutti, et pour cause la base n'est pas cohérente... Si je te proposais cela c'est AMHA qu'il y un manque dans le processus quelque part. Je pense que Benoît me rejoindra dans mon raisonnement. Je ne cherche pas à te « vendre » quelque chose, mais juste à vous aider à améliorer la qualité de vos données. tony. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: chemit@codelutin.com twitter: https://twitter.com/tchemit
comme tu le dis, on ne va pas batailler... On est d'accord sur le besoin, pas sur la solution et l'organisation à mettre en place. Ce n'est pas le problème d'acheter une prestation, la solution que tu proposes n'est tout simplement pas la meilleure étant donnée notre organisation. Le seul point essentiel au niveau de Tutti, pour éviter de vous solliciter en cas de problème et de perdre du temps comme tu le soulignes, est de pouvoir avoir la requête qui pose problème dans les logs. C'est ma seule demande car elle répondra à tous nos problèmes de diagnostique (sur les données, sur les référentiels...), sans avoir besoin de faire évoluer la fonctionnalité par la suite. En plus, dans le cas présent, mettre une procédure au niveau du système central n'aurait pas permis de détecter l'erreur : l'erreur n'est pas présente dans le système central. C'est en générant la base de référentiel en passant par allegro et en partant d'une base existante (et non d'une base vierge) que le problème est survenu. On pourra reprendre cette discussion lors de notre prochain point si tu veux. Christian Le 26/01/2016 09:43, Tony Chemit a écrit :
On Tue, 26 Jan 2016 09:31:25 +0100 Christian BONNET <Christian.Bonnet@ifremer.fr> wrote:
bonjour,
effectivement je n'avais pas compris ça.
La complexité de l'exploitation du système halieutique et en particulier du référentiel fait que l'équipe d'exploitation développe elle même ces propres traitements de vérification. Il s'agit généralement de requêtes exécutées directement sur la base par un outil SQL. Le travail est en cours et en consolidation permanente donc l'organisation ne collerait pas avec la réalisation d'un outil comme tu le proposes (car il faudrait le faire évoluer trop souvent).
Je ne suis pas d'accord avec toi sur ce point.
Le fait de se retrouver avec un référentiel incohérent sur une application finale n'est pas normale.
Il y a un certain nombre de choses qui ne varieront jamais :
* périodes sur les navires cohérentes par exemple.
Quoiqu'il en soit, je ne dis ça que pour vous; le temps que je passe à diagnostiquer cela c'est du temps perdu sur le développement client et ce n'est pas moi qui en pâtit.
Je ne vais pas batailler avec toi Christian, tout en ne comprenant pas ton point de vue. Oui je sais bien l'exploitation ce n'est pas mon domaine; sauf que tu te retournes vers moi quand ça ne fonctionne pas dans Tutti, et pour cause la base n'est pas cohérente...
Si je te proposais cela c'est AMHA qu'il y un manque dans le processus quelque part. Je pense que Benoît me rejoindra dans mon raisonnement.
Je ne cherche pas à te « vendre » quelque chose, mais juste à vous aider à améliorer la qualité de vos données.
tony.
-- Site Ifremer <http://www.ifremer.fr> Christian BONNET Centre de Brest ZI de la pointe du diable CS 10070 - 29280 Plouzané Informatique et Données Marines Ingénierie des Systèmes d'Information christian.bonnet@ifremer.fr <mailto:christian.bonnet@ifremer.fr> www.ifremer.fr <http://www.ifremer.fr> Tel : +33 (0)2.98.22.46.16 Fax : +33 (0)2.98.22.46.44
participants (2)
-
Christian BONNET -
Tony Chemit