DynamoDB — can not use both expression and non-expression parameters

En bref — Ta requête a défini un paramètre hérité (KeyConditions, QueryFilter, ScanFilter, AttributesToGet, Expected, AttributeUpdates, ConditionalOperator) et son équivalent expression (KeyConditionExpression, FilterExpression, ProjectionExpression, ConditionExpression, UpdateExpression) dans le même appel. DynamoDB interdit de mélanger les deux familles. Retire le paramètre hérité et utilise uniquement les expressions.

Ce que ça signifie

ValidationException: Can not use both expression and non-expression parameters in
the same request: Non-expression parameters: {KeyConditions} Expression
parameters: {KeyConditionExpression}

# what the engine actually returns, reproduced against DynamoDB Local:
ValidationException: Can not use both expression and non-expression parameters in the same request: Non-expression parameters: {KeyConditions} Expression parameters: {KeyConditionExpression}

DynamoDB a deux générations de paramètres. La famille héritée (KeyConditions, QueryFilter, ScanFilter, AttributesToGet, Expected, AttributeUpdates, ConditionalOperator) précède les expressions ; la famille expression (KeyConditionExpression, FilterExpression, ProjectionExpression, ConditionExpression, UpdateExpression) l'a remplacée. Une seule requête doit s'engager sur une seule famille — le guide développeur est explicite : DynamoDB « n'autorise pas le mélange de paramètres conditionnels hérités et de paramètres d'expression dans un seul appel », même quand ils couvrent des préoccupations sans rapport.

Pourquoi ça arrive

  • Code à moitié migré — tu as ajouté KeyConditionExpression mais laissé un ancien KeyConditions sur le même objet de paramètres.
  • Une collision de projectionAttributesToGet (hérité) aux côtés de ProjectionExpression.
  • Une collision de filtreScanFilter/QueryFilter aux côtés de FilterExpression.
  • Une collision d'écritureExpected/AttributeUpdates aux côtés de ConditionExpression/UpdateExpression.
  • Une bibliothèque utilitaire qui injecte une valeur héritée par défaut pendant que tu définis la forme expression.

Comment le corriger

  1. Supprime le paramètre hérité. Ne garde que la forme expression : KeyConditionExpression plutôt que KeyConditions, FilterExpression plutôt que ScanFilter/QueryFilter, ProjectionExpression plutôt que AttributesToGet, ConditionExpression/UpdateExpression plutôt que Expected/AttributeUpdates.
  2. Déplace les valeurs dans des placeholders — les valeurs héritées en ligne deviennent des ExpressionAttributeValues (:v) et les noms réservés/complexes deviennent des ExpressionAttributeNames (#n).
  3. Audite tout l'objet de paramètres — le conflit peut opposer deux préoccupations différentes (p. ex. projection héritée + condition de clé expression), pas seulement la même.
  4. Préfère les expressions partout — AWS ne conserve les paramètres hérités que pour la rétrocompatibilité et recommande les paramètres d'expression pour tout code nouveau ; standardiser sur les expressions évite cette classe d'erreur.

Tu modernises de l'ancien code de requête ? Prototype d'abord la requête tout-expression dans l'application de bureau DynoTable, puis copie les paramètres générés dans ton application.

Lance-le dans DynoTable

Le panneau de requête de DynoTable n'utilise que les paramètres d'expression — aucun champ KeyConditions ou ScanFilter hérité n'apparaît dans les requêtes générées. Ouvre une table avec ⌘K, construis une Query ou un Scan, et copie la KeyConditionExpression et les maps d'attributs émises dans ta migration.

Sers-toi du Query Builder pour prototyper la requête tout-expression avant de refactoriser ton vieux code SDK. Le staging (⌘S) te laisse tester la nouvelle requête sur des données en direct sans valider d'écriture. Change de profil avec ⌘P ; configure-les sous Settings → Profiles avec Test Connection. Vois Se connecter à AWS et Installation. Les paramètres hérités KeyConditions et ScanFilter n'apparaissent nulle part dans les requêtes générées par DynoTable. Si ton wrapper SDK les injecte encore, journalise l'objet params complet et supprime chaque clé héritée avant que l'appel n'atteigne DynamoDB.

Sources

Erreurs liées

Références

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

Travaille avec DynamoDB sans la Console

Un client de bureau rapide pour DynamoDB qui exécute le vrai SQL que DynamoDB ne peut pas — JOINs, GROUP BY, agrégations — avec édition visuelle et un agent IA sur tes propres clés Bedrock.

Essai gratuit de 30 jours, sans carte bancaire — ensuite la formule Gratuit, sans limite de durée.