CloudStorageTool méthode list();

Bonjour,
Sur notre projet on fait une recherche sur GCP pour récupérer le dernier fichier déposé d’un de notre connexe, on a utilise CloudStorageTool et plus précisément la méthode list() pour lister les fichiers et prendre le dernier, notre souci c’est que la méthode ne peut pas lister plus que 1000 fichiers. A-t-on un moyen pour avoir toute la liste des fichiers?

[Platform]
Status=OK
Version=5.1.22
BuiltOn=2021-12-29 12:44
Git=release/a4a4aafa93310ec3387ad178ae2001072320c3f3
Encoding=UTF-8
EndpointIP=10.144.25.191
EndpointURL=http://mla-api-79b95d567b-4j2r9:8080
TimeZone=Europe/Paris
SystemDate=2022-01-27 15:59:38

Merci pour votre retour
Laila B

Il n’y a pas de limite en dur sur le nombre de résultats retournés dans le code de la classe helper CloudStorageTool, la limite par défaut doit donc être au niveau de la lib sous jacente (Apache JClouds).

Visiblement il y a une méthode pour forcer le nombre max de résultats => on va ajouter une variante de la méthode list avec la possibilité de spécifier une valeur pour ce nombre. Ce sera dispo dans la prochaine révision 5.1.27 qui sera poussée ce WE

Cela dit il faudrait surtout revoir votre stratégie de stockage de ces fichiers car quand vous en aurez plusieurs millions ce sera absolument catastrophique en termes de performances et de consommation mémoire de remonter toute la liste pour trouver le plus récent…

1 Like

Merci pour ton retour David, on attend la version 5.1.27. Par contre on voulait aussi voir au niveau du résultat retourné de la méthode list(), on a un json de la forme {
"size ":14499, "name ":“renault/all/XXXXXXXXXXX”,
"modified ":“Mon, 10 Jan 2022 22:06:55 +0100”,
"etag ":“CInetLuLqPUCEAE=”,
"uri “XXXXX”
}, On a essayé de faire la purge sur GCP mais cela nous a posé un souci aussi on récupère le mauvais fichier car la méthode nous renvoie la dernière date de modification et pas de création , y-a-il un moyen d’avoir dans le json retourné par la méthode list() la date de création ?

Laila B

L’info de la date de création est à priori disponible dans les APIs JClouds => c’est désormais ajouté dans ce qui est retourné par la méthode list => ce sera l’attribut created au même niveau que modified

Attention: à voir si dans le cas du storage cloud Google cette valeur est effectivement remontée : les APIs JClouds sont communes à plusieurs types de storages, tous ne fournissent pas forcément les mêmes infos… A tester chez vous quand ce sera livré (dans la 5.1.27 aussi)

1 Like

Super Merci David, on fera le test dès qu’on a la nouvelle version :slight_smile:

Bonjour,
On a déployé la dernière version :
[Platform]
Status=OK
Version=5.1.27
BuiltOn=2022-01-30 19:16
Git=release/b227ee3270e90962ec6ec8002f60513da75b1301
Encoding=UTF-8
EndpointIP=172.20.181.214
EndpointURL=http://mla-api-66499cc8df-5nwfj:8080
TimeZone=Europe/Paris
SystemDate=2022-02-02 11:30:38

Par contre, je ne vois pas de différence :

  • Je n’ai pas de date de création dans le retour de la méthode.

  • La limite est toujours à 1000.

  1. pour la creation date, comme dit précédemment si l’info n’est pas remontée par le storage dans les metadata du fichier, on ne peut rien faire… Nous appelons la méthode ad hoc de la lib JClouds: StorageMetadata.getCreationDate => il y est dit “possibly null.” c’est à dire null si non fourni par le storage

  2. pour positionner explicitement le nombre de fichiers max retournés il faut utiliser la nouvelle variante de CloudStorageTool.list avec la limite explicite en argument: CloudStorageTool.list. Là aussi on passe la valeur à la méthode ad hoc de la lib JClouds cf. ListContainerOptions.maxResults. Si vous utilisez bien cette nouvelle méthode avec un max > 1000 et que ça ne retourne toujours que 1000 fichiers alors je pense que cette limite est configurée au niveau du storage.

Merci pour ton retour David, je vais refaire mes tests en prenant en compte les nouveaux éléments.
On a eu une problème sur cette version, on fait les appels API via un token, après un premier appel le token expire ce qui est pas le cas sur la version 5.11.22.
On a fait un rollback sur notre environnement de développement ==> le token n’expire pas
Y-a-il une modification qu’on doit prendre en compte par rapport à la nouvelle version 5.1.27?

Il y a le même sujet de token expiré dans ce post Erreur “New token is expired” lors de la consommation d’objet service-simplicite (le retour) - #12 by david

Ne mélangeons pas les sujets, ici il n’est question que de CloudStorageTool dans les révisions >= 5.1.27

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.