[GeoNetwork-users-fr] Valeur de localId non utilisée lors d'un import

GeoNetwork Utilisateurs GeoNetwork
1

Bonjour,

encore un petit "rapport de bug", qui est aussi valide pour GeoNetwork à priori.. le paramêtre 'localId' dans le fichier info.xml n'est pas utilisé lors de l'import d'une donnée, quoi qu'il arrive geosource génère un nouvel Id/serial a partir de SerialFactory : (./src/org/fao/geonet/kernel/mef/Importer.java, ~ligne 260 (id.add))

La doc précise dans la description du format MEF que cet id, si présent sera utilisé au lieu d'en générer un.. (ou alors j'ai mal compris)

Ca peut paraitre pas grand chose, mais quand on veut importer une donnée avec des fichiers attachés, et donc que dans metadata.xml on a une url de type /geonetwork/srv/fr/resources.get?id=XXX&fname=monfichier&access=public, ca pose probleme.. vu que le XXX n'est connu qu'une fois la donnée importée, ca fait un peu serpent qui se mord la queue. Evidemment, on peut contourner ca en 'devinant' le prochain identifiant donné par SerialFactory, mais c'est pas très propre.

Le code pour implémenter ca a l'air trivial au premier abord, mais mon java est trop rouillé, et je ne me suis pas encore penché sur la procédure pour recompiler geosource.. a priori, il faut rendre conditionnel l'appel a id.add(), et lui passer la valeur de localId si elle est présente dans le info.xml, et non déja existante dans la bd. Mais je connais pas encore suffisamment le code pour être catégorique.

--
Cdlt,
Landry Breuil
Administrateur de données du CRAIG

2

Landry Breuil a écrit :

Bonjour,

encore un petit "rapport de bug", qui est aussi valide pour GeoNetwork à priori.. le paramêtre 'localId' dans le fichier info.xml n'est pas utilisé lors de l'import d'une donnée, quoi qu'il arrive geosource génère un nouvel Id/serial a partir de SerialFactory : (./src/org/fao/geonet/kernel/mef/Importer.java, ~ligne 260 (id.add))

La doc précise dans la description du format MEF que cet id, si présent sera utilisé au lieu d'en générer un.. (ou alors j'ai mal compris)

Ca peut paraitre pas grand chose, mais quand on veut importer une donnée avec des fichiers attachés, et donc que dans metadata.xml on a une url de type /geonetwork/srv/fr/resources.get?id=XXX&fname=monfichier&access=public, ca pose probleme.. vu que le XXX n'est connu qu'une fois la donnée importée, ca fait un peu serpent qui se mord la queue. Evidemment, on peut contourner ca en 'devinant' le prochain identifiant donné par SerialFactory, mais c'est pas très propre.

Et c'est finalement un bug très bloquant pour moi... j'ai un .zip avec ~200 données dedans, et je ne sais pas dans quel ordre elles vont être importées, donc je ne peux pas 'prédire' l'id qui sera donné a chacune par geosource, donc je ne peux pas 'précalculer' l'URL pour le téléchargement du fichier. Tout ca parce que MEF2Visitor.java utilise la méthode listFiles() de java.io.file pour parcourir les sous-repertoires du zip, méthode qui stipule :
There is no guarantee that the name strings in the resulting array will appear in any specific order; they are not, in particular, guaranteed to appear in alphabetical order.

Et je ne vais pas m'amuser a prendre mes 200 données une par une, et les importer une par une....

Quelqu'un aurait une piste ? En attendant, et en désespoir de cause, je vais regarder le code pour lui faire utiliser localId...

--
Cdlt,
Landry Breuil
Administrateur de données du CRAIG

3

Landry Breuil a écrit :

Quelqu'un aurait une piste ? En attendant, et en désespoir de cause, je vais regarder le code pour lui faire utiliser localId...

Bon, finalement j'ai craqué, et j'ai fixé Importer.java, ca aura été plus simple que je pensais - le diff est en piece jointe. Ca marche pour moi sur l'import d'un batch de 3 données, mais je n'ai pas testé toutes les configurations envisageables. Au passage, comment marche le logging, ie comment activer les différentes catégories de Log.debug ? j'ai l'impression qu'uniquement une seule partie sont envoyés a tomcat..

--
Cdlt,
Landry Breuil
Administrateur de données du CRAIG

(attachments)

use-localId-in-Importer.diff (743 Bytes)

4

Landry Breuil a écrit :

Landry Breuil a écrit :

Quelqu'un aurait une piste ? En attendant, et en désespoir de cause, je vais regarder le code pour lui faire utiliser localId...

Bon, finalement j'ai craqué, et j'ai fixé Importer.java, ca aura été plus simple que je pensais - le diff est en piece jointe. Ca marche pour moi sur l'import d'un batch de 3 données, mais je n'ai pas testé toutes les configurations envisageables. Au passage, comment marche le logging, ie comment activer les différentes catégories de Log.debug ? j'ai l'impression qu'uniquement une seule partie sont envoyés a tomcat..

ok, pour ce dernier point, j'ai trouvé le log4j.cfg.

deuxième version du diff, qui ce coup-ci déplace la ligne
'groupId = Util.getParam(params, Params.GROUP);' en dehors du if(), pour que la valeur soit prise en compte dans tous les cas... je me suis retrouvé avec 200 données n'ayant pas de groupowner. Pareil, le diff fixe le problème pour moi, cependant quand je fais une recherche sur un groupe, ca ne me renvoie pas encore les données appartenant a ce groupe.. mais ce n'est pas lié je pense.

--
Cdlt,
Landry Breuil
Administrateur de données du CRAIG

(attachments)

use-localId-and-groupId-in-Importer.diff (2.25 KB)

5

Bonjour Landry,
Merci pour ce retour, en effet la valeur de localId n'est pas utilisée lors
de l'import dans GéoSource.

Merci pour la contribution également, elle a permit de tester et de modifier
le comportement lors de l'import.
Ce diff a donc été intégré au code source de GéoSource.
Je me suis, cependant, permis quelques modifications que j'explique
ci-dessous.

Dorénavant, si une valeur de localId est présente dans le fichier info.xml,
et qu'il n'existe aucune métadonnées dans la base avec cet identifiant,
alors celui-ci est utilisé.
Sinon, un nouvel Id/serial est généré à partir de SerialFactory comme
c'était le cas auparavant.

2009/8/20 Landry Breuil <breuil@anonymised.com>

Landry Breuil a écrit :

Landry Breuil a écrit :

Quelqu'un aurait une piste ? En attendant, et en désespoir de cause, je
vais regarder le code pour lui faire utiliser localId...

Bon, finalement j'ai craqué, et j'ai fixé Importer.java, ca aura été

plus simple que je pensais - le diff est en piece jointe. Ca marche pour moi
sur l'import d'un batch de 3 données, mais je n'ai pas testé toutes les
configurations envisageables.

Au passage, comment marche le logging, ie comment activer les différentes

catégories de Log.debug ? j'ai l'impression qu'uniquement une seule partie
sont envoyés a tomcat..

ok, pour ce dernier point, j'ai trouvé le log4j.cfg.

deuxième version du diff, qui ce coup-ci déplace la ligne
'groupId = Util.getParam(params, Params.GROUP);' en dehors du if(), pour
que la valeur soit prise en compte dans tous les cas... je me suis retrouvé
avec 200 données n'ayant pas de groupowner.

Une correction a également été apportée au niveau du "groupOwner", afin
d'eviter de perdre cette information lors d'un export/import.
Le paramètre groupId n'a cependant pas été déplacé car il permet lors de
l'import d'un fichier MEF/ZIP d'utiliser les informations de privlièges
contenues dans le fichier info.xml.

Pareil, le diff fixe le problème pour moi, cependant quand je fais une
recherche sur un groupe, ca ne me renvoie pas encore les données appartenant
a ce groupe.. mais ce n'est pas lié je pense.

--
Cdlt,
Landry Breuil
Administrateur de données du CRAIG

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
GeoNetwork-users-fr mailing list
GeoNetwork-users-fr@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-users-fr

Cordialement,

--
Mathieu Coudert