Outil gratuit

Générateur de requêtes DynamoDB

Compose la requête Query ou Scan complète — table, index, condition de clé, filtre, projection, Limit, ordre de tri, lectures cohérentes et pagination — et copie un programme exécutable AWS SDK v3, CLI ou boto3, ou l’instruction PartiQL.

Compose ta requête
Options de la requête
Code exécutable
import { DynamoDBClient, QueryCommand } from "@aws-sdk/client-dynamodb";

const client = new DynamoDBClient({});

const params = {
  "TableName": "Orders",
  "KeyConditionExpression": "#hashKey = :hashKeyValue AND begins_with(#rangeKey, :rangeKeyValue)",
  "ExpressionAttributeNames": {
    "#hashKey": "pk",
    "#rangeKey": "sk"
  },
  "ExpressionAttributeValues": {
    ":hashKeyValue": {
      "S": "USER#123"
    },
    ":rangeKeyValue": {
      "S": "ORDER#"
    }
  },
  "Limit": 25
};

const items = [];
let lastEvaluatedKey;
do {
  const page = await client.send(
    new QueryCommand({ ...params, ExclusiveStartKey: lastEvaluatedKey })
  );
  items.push(...(page.Items ?? []));
  lastEvaluatedKey = page.LastEvaluatedKey;
} while (lastEvaluatedKey);

console.log(items);

Du pattern d’accès à la requête exécutable

L’expression est rarement tout le travail. Une Query de production décide aussi quel index lire, combien d’items évaluer par requête, dans quel sens parcourt la clé de tri, si la lecture doit être fortement cohérente, et ce qui se passe quand la réponse revient avec un LastEvaluatedKey. Ces paramètres au niveau de la requête vivent hors de la chaîne d’expression — et c’est là que les snippets copiés-collés déraillent le plus souvent.

Ce générateur traite la requête comme l’unité de travail. Tu composes la condition de clé, le filtre et la projection sur le même modèle typé et à l’épreuve des mots réservés que notre Générateur d’expressions, puis tu règles à côté les options de la requête. La sortie n’est pas un fragment : c’est un programme que tu peux exécuter — imports, initialisation du client, l’appel lui-même et, quand tu actives « Récupérer toutes les pages », la boucle ExclusiveStartKey qui épuise chaque page de résultats.

Le code généré reste honnête pour chaque cible. L’AWS CLI pagine toute seule, donc son Limit devient --page-size et une exécution en une seule requête reçoit --no-paginate ; PartiQL refuse les paramètres qui relèvent de l’API ExecuteStatement plutôt que de l’instruction ; et une Query descendante devient un ORDER BY sur ta clé de tri là où c’est exprimable.

Tu n’as besoin que de l’expression elle-même — une expression de condition, de filtre ou de mise à jour avec ses maps de placeholders, pour l’une des six opérations ? Le Générateur d’expressions DynamoDB est fait exactement pour ça. Tu hésites encore entre les deux opérations de lecture ? Query vs Scan détaille quand chacune est le bon choix.

Questions fréquentes

En quoi est-ce différent du Générateur d’expressions DynamoDB ?

Ils se partagent volontairement le problème. Le Générateur d’expressions porte sur la syntaxe des expressions — conditions de clé, filtres, expressions de mise à jour et de condition avec leurs maps ExpressionAttributeNames/Values — pour les six opérations, et il émet la commande brute. Le Générateur de requêtes porte sur la requête Query ou Scan complète : table et index, condition de clé, filtre, projection, plus les paramètres au niveau de la requête que l’outil d’expressions n’expose pas (Limit, ordre de tri, ConsistentRead, ExclusiveStartKey), et il émet un programme exécutable avec l’initialisation du client et une boucle de pagination optionnelle.

Que limite réellement Limit dans une Query ou un Scan ?

Limit plafonne le nombre d’items que DynamoDB évalue par requête, pas le nombre d’items correspondants que tu reçois. Les filtres s’appliquent après la lecture : une Query avec Limit 25 et une FilterExpression peut donc renvoyer moins de 25 items — voire aucun — tout en consommant la capacité de lecture de tout ce qui a été évalué, et la pagination reprend à partir de LastEvaluatedKey. Dans l’AWS CLI, qui pagine automatiquement, le même paramètre se règle avec --page-size.

Comment fonctionne la pagination DynamoDB (LastEvaluatedKey) ?

Une réponse de Query ou de Scan qui contient encore des données inclut un LastEvaluatedKey — la clé primaire du dernier item lu. Tu le renvoies comme ExclusiveStartKey dans la requête suivante et tu répètes jusqu’à recevoir une réponse sans lui. Active « Récupérer toutes les pages » et les programmes SDK v3 et boto3 générés contiennent exactement cette boucle ; l’AWS CLI parcourt les pages toute seule, sauf si tu passes --no-paginate.

Quand puis-je utiliser une lecture fortement cohérente ?

ConsistentRead fonctionne sur les tables de base et les index secondaires locaux, mais pas sur les index secondaires globaux — une Query sur un GSI avec ConsistentRead activé est rejetée. Une lecture fortement cohérente consomme aussi deux fois plus de capacité de lecture qu’une lecture à cohérence à terme. C’est un paramètre d’API et non une partie du texte de l’instruction PartiQL — c’est pourquoi l’onglet PartiQL la refuse honnêtement.

Ce que je saisis ici est-il envoyé quelque part ?

Non. C’est une page statique : la requête est composée et le code généré entièrement dans ton navigateur, si bien que les noms de table, les valeurs de clé et les filtres n’atteignent jamais un serveur. « Copier le lien » range toute la requête dans l’URL — partager ce lien est la seule façon pour ce que tu as tapé de quitter la page, et cela reste entre tes mains.

Travaille avec DynamoDB sans la Console

DynoTable est un client de bureau rapide pour DynamoDB — parcours les tables, exécute des requêtes de style SQL et édite les items en local.