Générateur d’expressions DynamoDB
Choisis une opération, construis la requête visuellement et copie une expression correcte et compatible avec les mots réservés — avec ses ExpressionAttributeNames et Values — en AWS SDK v3, CLI, boto3 ou PartiQL.
Pourquoi écrire des expressions DynamoDB à la main est source d’erreurs
Une requête DynamoDB échoue rarement sur la partie évidente. Elle échoue parce que status est un mot réservé qui a besoin d’un alias #, parce qu’un id numérique a été envoyé comme chaîne et n’a rien correspondu, ou parce qu’un FilterExpression et un ConditionExpression ont réutilisé le même placeholder :v0. Chacune est une petite erreur qui produit une requête qui s’exécute mais renvoie les mauvaises lignes — le pire genre à déboguer.
Ce builder assemble toute la requête à partir d’un modèle typé. Chaque nom d’attribut est aliasé, chaque valeur porte un type DynamoDB explicite, et les placeholders de clé, de filtre, de condition et de mise à jour vivent dans des espaces de noms distincts, de sorte que les collisions sont impossibles par construction. La sortie est construite à partir des tags de type, pas devinée à partir de ton texte — un nombre reste un nombre, une chaîne base64 reste binaire.
Les expressions de mise à jour et les écritures conditionnelles bénéficient du même traitement : compteurs atomiques, if_not_exists, list_append, REMOVE sur un index de liste, ADD/DELETE sur des sets et conditions de verrouillage optimiste s’assemblent tous en un seul UpdateExpression et ConditionExpression corrects. L’onglet PartiQL est honnête — quand une primitive n’a pas de forme PartiQL, il t’indique laquelle plutôt que d’émettre une instruction qui se comporte mal en silence.
Tu choisis d’abord entre une Query et un Scan ? Query vs Scan explique la différence, et Exemples PartiQL couvre en profondeur la syntaxe de style SQL.
Questions fréquentes
Qu’est-ce qu’un ExpressionAttributeName, et pourquoi les préfixes # et : ?
Les expressions DynamoDB ne peuvent pas référencer directement un nom d’attribut qui est un mot réservé (comme name, status ou size), et un placeholder de valeur garde les données réelles hors de la chaîne d’expression. Chaque nom d’attribut est donc aliasé avec un placeholder # dans ExpressionAttributeNames et chaque valeur avec un placeholder : dans ExpressionAttributeValues. Ce builder génère ces maps pour toi, pour qu’un mot réservé ne casse jamais ta requête.
Pourquoi dois-je choisir un type (S, N, B…) pour chaque valeur ?
DynamoDB est typé au niveau de l’attribut : le nombre 5 est { "N": "5" } et la chaîne "5" est { "S": "5" } — des valeurs différentes qui correspondent à des items différents. Une saisie de texte ne peut pas les distinguer, donc le builder te demande de taguer chaque valeur. La sortie SDK, CLI, boto3 et PartiQL générée est construite à partir de ce tag, jamais devinée à partir du texte, si bien qu’un id numérique reste un nombre et qu’un blob base64 reste binaire.
Peut-il construire des expressions de mise à jour et des écritures conditionnelles ?
Oui. Update couvre SET (y compris if_not_exists, les compteurs atomiques +/- et list_append), REMOVE (y compris un index de liste comme #a[2]), ADD (nombre ou set) et DELETE (membres d’un set) — combinés en un seul UpdateExpression. Les écritures conditionnelles ajoutent un ConditionExpression à Update, Put ou Delete pour le verrouillage optimiste (attribute_not_exists, une vérification de version, etc.). Les conditions de clé et les conditions de valeur utilisent des espaces de noms de placeholders distincts pour ne jamais entrer en collision.
Pourquoi PartiQL est-il parfois « inexprimable » ?
PartiQL couvre la plupart des lectures et écritures, mais quelques primitives DynamoDB n’ont pas de forme PartiQL : un INSERT conditionnel, les actions de mise à jour ADD/DELETE sur les sets, et des fonctions comme size(), list_append et if_not_exists. Quand ta requête utilise l’une d’elles, l’onglet PartiQL t’indique exactement quelle fonctionnalité est inexprimable au lieu d’émettre une instruction qui ferait silencieusement la mauvaise chose — utilise la sortie SDK, CLI ou boto3 dans ces cas.
Mes données quittent-elles le navigateur ?
Non. Le builder s’exécute entièrement côté client — il génère les expressions et les extraits de code dans ton navigateur et rien de ce que tu saisis n’est envoyé à un serveur. La fonction « Copier le lien » de l’URL sérialise ta requête dans le lien lui-même pour que tu puisses le partager ou le mettre en favori, mais cela reste entre tes mains.