Produits Entr'ouvert » Passerelle

rows_values = jsonfield.JSONField(editable=False)

Il semble que j'aurais du développer pourquoi "ça ne va pas être top sur des beaucoup plus grosses listes". Une des raisons c'est se trouver devoir tout charger en mémoire. Et ici, donc, ça ne change rien, c'est juste que plutôt que sortir les dizaines ou centaines de Mo d'un fichier ils vont sortir de la db. (et j'aime beaucoup postgresql mais pour autant je n'y taperais pas des centaines de Mo dans un champ texte).

Rien à voir avec le stockage en base, mais https://dev.entrouvert.org/issues/14404#note-5

Et on peut aussi vraiment se dire que l'exemple donné a été résolu de manière spécifique, qu'à partir d'un certain volume de données ça devrait être le cas, que le connecteur tableur ne peut pas tout accueillir.

Frédéric Péters a écrit :

qu'à partir d'un certain volume de données ça devrait être le cas, que le connecteur tableur ne peut pas tout accueillir.

et qu'inversement, que pour des petites listes de quelques lignes et quelques colonnes, gérer ça via un CSV, c'est chiant.

• séparer le début du patch index -> key dans son propre commit
• il me semble que si le CSV est vide ça va boucler infiniment:
  

      def get_cached_rows(self):
          found = False
          for row in TableRow.objects.filter(resource=self):
              found = True
              yield row.data
          if not found:
              # if there was no row probably the data was not cached in database
              # yet.
              self.cache_data()
              for data in self.get_cached_rows():
                  yield data
  

  
  (J'ai vérifié, un fichier vide donne bien 0 ligne de CSV:
  

  In [3]: list(csv.reader(StringIO.StringIO('')))
  Out[3]: []
  

  )
• anecdotique, le champ line_number me semble inutile, dans le cas d'une création dans une unique transaction on est certain que id sera séquentiellement alloué, donc order by id suffirait.

Sur le fond je vois ça comme un pas vers l'application des critères directement aux lignes du modèle (via le type JSON natif de postgres) mis en cache, sinon je ne vois pas bien le progrès par rapport à CSV (il faudrait mesurer mais j'ai l'impression que ça n'ira pas tellement plus vite) mais ça doit éventuellement améliorer les choses pour des gros fichiers ODT ou XLS (il me semble que c'était un des cas d'usage initial, mais on aurait pu dans ce cas mettre en cache une version CSV sur disque).

séparer le début du patch index -> key dans son propre commit

Voilà, 0001.

il me semble que si le CSV est vide ça va boucler infiniment:

En effet; modulo qu'un CSV vide va être refusé parce qu'il n'arrivera pas à en déterminer le délimiteur de colonnes. Mais j'ai pu faire un test en mettant un ods vide pour valider la correction.

anecdotique, le champ line_number me semble inutile, dans le cas d'une création dans une unique transaction on est certain que id sera séquentiellement alloué, donc order by id suffirait.

Je le trouve utile pour à un moment pouvoir aider au debug, permettre de pointer l'usager vers la ligne de son fichier.

Sur le fond je vois ça comme un pas vers l'application des critères directement aux lignes du modèle (via le type JSON natif de postgres) mis en cache, sinon je ne vois pas bien le progrès par rapport à CSV (il faudrait mesurer mais j'ai l'impression que ça n'ira pas tellement plus vite) mais ça doit éventuellement améliorer les choses pour des gros fichiers ODT ou XLS (il me semble que c'était un des cas d'usage initial, mais on aurait pu dans ce cas mettre en cache une version CSV sur disque).

La motivation présente est bien d'éviter les bugs de lecture d'ods (c'est noté dans le commentaire au-dessus). Mais à un moment pouvoir profiter des requêtes JSON, tout à fait. (même si j'ai en parallèle l'idée que la partie "requêtes" pourrait être sortie de ce connecteur particulier, pouvoir s'appliquer à tout autre connecteur fournissant l'API "données", et qu'il n'y aura alors pas nécessairement de db en backend).