Bonjour,
J’arrive à réaliser un POST (ou un PUT) d’un fichier en passant à CloudStorageTool le ‘content’ dans un buffer byte.
Est-il possible de fournir un stream à la place du bufffer byte pour pouvoir supporter l’upload de fichiers à gros volume ? Si oui, comment ?
Merci beaucoup pour votre support.
Oui il devrait y avoir des interfaces en stream/buffer pour éviter de saturer la mémoire.
On va ajouter un champ path vers un document dans le JSONObject du CloudStorageTool.put.
Je passe le sujet en feature request.
Après analyse :
openStream retourne un InputStream, car le service get monte également tout en mémoire ce qui n’est pas toujours souhaitable.Ce sera poussé en V5 et backporté en V4.
Bonjour François,
super merci beaucoup!
Je pense qu’on va en effet avoir besoin de pouvoir copier dans l’InputStream le contenu qui arrive déjà via un stream et qui est actuellement transformé en byte uniquement pour le post/put (j’envisageais en l’occurrence un simple IOUtils.copy(doc_src_outputStream, cloudstoragetool_inputStream))
Les interfaces Cloud prennent un input-stream en entrée, pas besoin d’un output.
Ok on va ajouter une méthode :
public String put(String name, String mime, long length, InputStream is)
throws Exception
Car la source n’est pas toujours un fichier physique
exemple quand la base est en BLOB : pas de dbdoc physique, tout dans la table m_document
obj.getField("myDocField").getDocument().getInputStream()
Bonjour François,
Nous avons la même problématique qui se présente sur notre projet mais pour l’import de fichier.
Peux-tu me confirmer que vous intégrez la consommation de fichiers volumineux ?
Peux-tu m’indiquer une date ou cette fonctionnalité sera intégrée dans Simplicité ?
Enfin, je comprends que la méthode lit du contenu pour la réécrire dans un fichier sur le serveur Simplicité (et inversement pour l’envoi).
Cela veut-il dire que nous ne pourrons pas envoyer de fichier zip ?
Une fonctionnalité d’upload et de download de fichier est-elle envisageable ?
Merci d’avance pour ton retour.
Jean-Baptiste
En lecture :
On va ajouter la méthode InputStream CloudStorageTool.openStream(String filename)
donc à vous d’implémenter derrière le read + close de ce flux où vous voulez = vers un output-stream (fichier local…) qui ne consomme pas de mémoire non plus.
En écriture :
Oui on peut envoyer un inputStream qui pointe sur un fichier ZIP préparé avant (fichier temp ou dbdoc).
A tester sur de gros fichiers pour voir s’il n’y pas d’autres soucis (timeout, quota…)
Bonjour François,
j’ai vu qu’un nouveau build de la v4 avait été mis en ligne : Version=4.0.P25
BuiltOn=2021-06-01 15:33 (revision 896159a89e74fb4003ddcca8620f35d9e6b4090b).
Ce build inclut-il le support du streaming dans le CloudStorageTool ?
Quoi qu’il en soit, merci beaucoup pour ton support sur ce sujet.
Oui les commits datent du 31.
Les nouvelles méthodes put et openStream doivent être accessibles.
Pour info, la V5 a déjà fait la chasse aux byte-arrays hérités de la legacy V3/V4 (comme les import/exports standards CSV, XLS, ZIP… tous passés en stream), mais il en reste surement encore dans les placards.
Super! Merci beaucoup.
L’upgrade en V5 est dans le pipe mais la résorption de la dette technique n’est jamais prioritaire et si on ne peut pas la tronçonner en petits bouts ça coince (et là la V5 coince)…
Bonjour François,
L’update a t’il été fait sur la V5 ? Je ne le vois pas sur ma version 5.0.51.
Merci pour ton retour.
Jean-Baptiste
Dsl François, j’ai une désynchronisation entre Simplicité et mon Eclipse.
J’ai bien la méthode sur l’IDE Simplicité.
Jean-Baptiste BLANC
Dans les IDE externes il faut parfois forcer explicitement l’update Maven du projet (i.e. faire l’équivalent d’un mvn -U ...) pour que le repo Maven local récupère bien la dernière version de la lib Simplicité exposée par l’instance.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.