ValidationException: Unexpected from source

En bref — Le nom de table dans ta clause FROM PartiQL contient des caractères que l'analyseur n'accepte pas nus — le plus souvent un tiret. Entoure le nom de guillemets doubles (SELECT * FROM "my-table"). Les guillemets simples ne fonctionnent pas : en PartiQL ils désignent un littéral de chaîne, pas un identifiant.

Ce que ça signifie

ValidationException: Unexpected from source

L'analyseur PartiQL lit FROM my-table comme l'identifiant my suivi de jetons inattendus — le tiret n'est pas valide au sein d'un identifiant nu. Les noms de table DynamoDB peuvent légalement contenir -, . et _, donc un nom de table parfaitement valide peut quand même être inanalysable en PartiQL tant qu'il n'est pas entre guillemets. Il en va de même pour les noms qui entrent en collision avec des mots-clés PartiQL.

Pourquoi ça arrive

Le nom de table contient un tiret ou un point — users-prod, app.events. Les identifiants nus ne peuvent pas les porter.
Des noms de table générés par un framework — l'outillage qui suffixe un environnement ou une étape au nom de la table (par ex. Todo-dev) est la façon classique dont un tiret s'y glisse sans que tu l'aies choisi.
Interroger un index sans guillemets — la forme "table"."index" nécessite des guillemets doubles autour des deux parties.
Des guillemets simples au lieu de doubles — FROM 'my-table' échoue aussi : les guillemets simples désignent un littéral de chaîne en PartiQL, pas un nom.

Comment le corriger

Mets le nom de table entre guillemets doubles :
```
SELECT * FROM "users-prod" WHERE pk = 'USER#42'
```
Mets les deux parties entre guillemets doubles pour interroger un index :
```
SELECT * FROM "users-prod"."email-index" WHERE email = 'ada@example.com'
```
Réserve les guillemets simples aux valeurs de chaîne uniquement — les noms entre guillemets doubles, les valeurs entre guillemets simples. Les confondre produit exactement cette classe d'erreur d'analyse.
Mets les guillemets par défaut dans les instructions générées — si ton code interpole des noms de table dans du PartiQL, émets-les toujours entre guillemets doubles ; c'est valide même quand le nom n'en aurait pas strictement besoin.

L'éditeur PartiQL de DynoTable gère la mise entre guillemets des identifiants pour toi — avec des diagnostics inline et des corrections rapides pour exactement cette classe d'erreurs d'analyse — et le DynamoDB Expression Builder montre la requête Query/Scan native équivalente quand tu préfères contourner entièrement l'analyse PartiQL.

Lance-le dans DynoTable

L'éditeur PartiQL de DynoTable met automatiquement les noms de tables et d'index entre guillemets doubles — lance SELECT * FROM "my-table" avec ses diagnostics en ligne avant de coller l'instruction dans du code SDK. Ouvre la table avec ⌘K pour confirmer son nom exact (tirets compris) depuis la barre latérale.

Quand l'analyse PartiQL continue d'échouer, passe au Query Builder pour la requête native équivalente. Le changement de profil (⌘P) et Test Connection dans Settings → Profiles gardent l'instruction pointée sur la bonne table. Vois Se connecter à AWS et Installation.

Sources

PartiQL select statements for DynamoDB (vérifié le 2026-07-13)
Supported data types and naming rules (vérifié le 2026-07-13)

Reproduire l'erreur

Une instruction PartiQL dont la source FROM n'est pas un nom de table. L'analyseur la rejette avant même de chercher une table, donc ça se reproduit sur n'importe quel endpoint :

await client.send(new ExecuteStatementCommand({Statement: 'SELECT * FROM 123'}));

Sortie réelle :

ValidationException: Unexpected from source
HTTP 400

Compare avec un nom valide mais non quoté : SELECT * FROM repro s'analyse sans problème et échoue plus tard avec ResourceNotFoundException si la table n'existe pas. Unexpected from source est strictement une erreur d'analyse syntaxique : lis-la comme un signal de syntaxe, pas de table manquante.

Erreurs liées

DuplicateItemException — un INSERT PartiQL sur une clé existante.
ValidationException — la classe d'exception parente.
Apprends : Exemples PartiQL · SQL pour DynamoDB

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.

Reproduit le 2026-07-26 sur DynamoDB Local 2.x avec l'AWS SDK for JavaScript v3.1095.0 — la sortie ci-dessus est reproduite telle quelle.