Import

DynoTable importe des fichiers CSV, JSON et NDJSON dans une table existante — l'autre moitié de l'Export. Le fichier entier est vérifié avant qu'une seule ligne soit écrite, donc un fichier défectueux échoue avec des numéros de ligne au lieu de laisser tes données importées à moitié.

Ouvre-le avec le bouton Importer dans la barre d'outils de la table. L'import écrit dans la table, donc il faut une licence Essai ou Actif.

L'import charge des données dans une table qui existe déjà — il n'en crée jamais. Crée d'abord la table (et sa clé primaire), puis importe dedans.

Deux niveaux de fidélité

Exact — JSON / NDJSON écrit dans la forme réseau marshallée (DynamoDB-JSON). Rien n'est deviné : chaque valeur porte déjà son propre type, donc un export pris dans ce format se réimporte inchangé. C'est le format à utiliser quand les données comptent.

Pratique — CSV et JSON simple (non marshallé). Ces formats ne portent aucune information de type, donc DynoTable infère un type par colonne et te montre ce qu'il a choisi avant que tu valides. Pratique, et avec des pertes documentées — voir Où les fichiers pratiques perdent de l'information.

Colonnes et types

Les en-têtes du fichier deviennent des noms d'attributs. L'aperçu liste chaque colonne avec le type que DynoTable a inféré. Fais un clic droit sur l'en-tête d'une colonne pour la renommer si l'en-tête ne correspond pas à ton nom d'attribut, ou pour changer son Type de données quand celui inféré n'est pas ce que tu veux — un code produit composé uniquement de chiffres, par exemple, qui doit rester du texte plutôt que devenir un nombre.

La liste de types ne propose que ce que les valeurs de cette colonne peuvent réellement devenir, donc une colonne de texte simple ne proposera pas Map ou List. Si une colonne n'a qu'un seul type possible, aucune liste n'apparaît. Il n'y a pas d'écran de mapping au-delà de ça.

Ton fichier doit fournir la clé primaire complète de la table. Une ligne à qui il manque un attribut de clé, ou qui porte le mauvais type pour l'un d'eux, est refusée nommément.

Rien n'est écrit tant que le fichier entier n'est pas validé

L'import lit le fichier deux fois. La première passe valide chaque ligne et n'écrit rien ; seulement si le fichier passe, la seconde passe écrit.

• Les problèmes sont signalés avec des numéros de ligne (ou des positions d'item, pour un tableau JSON), jusqu'à 20 à la fois.
• Deux lignes avec la même clé dans un fichier sont refusées, et les deux positions te sont montrées — DynamoDB ne garderait silencieusement que la dernière.
• Corrige le fichier et appuie de nouveau sur Importer ; la boîte de dialogue reste sur le fichier que tu as choisi.

Importer remplace les items correspondants

Une ligne importée remplace tout item existant avec la même clé primaire, attribut pour attribut — elle n'y est pas fusionnée. Les attributs que l'ancien item avait et que le fichier n'a pas disparaissent.

L'import ne passe pas non plus par le staging, donc il n'y a ni étape de relecture ni retour en arrière possible. Contrairement à une modification mise en staging, un import ne peut pas être annulé depuis l'historique de l'app. Sur des données qui comptent pour toi, importe d'abord dans une copie de la table et vérifie le résultat.

Limites

Un fichier .json contient un seul grand tableau qui doit être parsé entièrement, ce qui explique pourquoi son plafond est plus bas. Le NDJSON — un item par ligne — est streamé à la place, donc il profite des 250 MB complets.

Où les fichiers pratiques perdent de l'information

Ça s'applique uniquement au CSV et au JSON simple. Le format DynamoDB-JSON marshallé n'en a aucun.

• Les types sont inférés depuis un échantillon d'environ les 200 premières lignes. Une colonne qui y semble numérique mais devient non numérique plus loin dans le fichier est refusée pendant la validation — le correctif est de corriger le fichier.
• Les sets et le binaire ne peuvent pas s'exprimer en CSV, donc ils ne peuvent pas en être importés.
• Les cellules vides sont ignorées, pas écrites comme chaînes vides. Un item n'aura simplement pas cet attribut.
• Les Maps et les Lists survivent au trajet. L'export les écrit dans une cellule CSV sous forme de texte JSON, et l'import reconnaît ce texte et reconstruit la structure. Si une colonne est vraiment du texte qui ressemble à du JSON, l'aperçu montre ce qu'elle est devenue et tu peux remettre le Type de données de cette colonne à String.
• Les très grands nombres en JSON simple perdent en précision avant même que DynoTable ne les voie — c'est une limitation propre à JSON. Utilise le DynamoDB-JSON pour les ID et les montants qui doivent rester exacts.
• Les marques de sécurité pour tableur sont traitées au retour. L'export préfixe d'une apostrophe les cellules qu'un tableur traiterait comme des formules. À l'import, '-5 redevient le nombre -5 et '+7 revient comme le texte +7 — mais une vraie formule comme '=SUM(A1) garde son apostrophe, définitivement. La retirer réarmerait ce que la marque existe pour désamorcer.

Progression, annulation et échecs

Un import en cours apparaît dans le dock Activité en bas de la barre latérale, avec une progression en direct, et continue pendant que tu travailles dans d'autres onglets. Tu peux l'Arrêter depuis là ; les lignes déjà écrites restent écrites.

Si DynamoDB throttle la table assez fort pour que certaines lignes ne puissent pas être écrites même après plusieurs nouvelles tentatives, l'import se termine et t'indique combien de lignes n'ont pas pu être écrites. Relancer le même fichier est sûr — les lignes qui ont déjà atterri sont simplement réécrites avec les mêmes valeurs.

Les entrées d'import restent dans le dock jusqu'à ce que tu les ignores : un import ne produit aucun fichier vers lequel pointer, donc cette ligne est la seule trace que l'exécution s'est terminée.