Two document paths overlap with each other

TL;DR — Une même UpdateExpression ne peut toucher chaque chemin de document qu'une seule fois, et aucun chemin ne peut se situer à l'intérieur d'un autre chemin que la même expression touche aussi. SET profile = :p, profile.email = :e se chevauche (profile.email est à l'intérieur de profile) ; nommer deux fois le même attribut aussi. Fonds l'enfant dans la valeur du parent, ou scinde en deux updates.

Ce que ça signifie

ValidationException: Invalid UpdateExpression: Two document paths overlap
with each other; must remove or rewrite one of these paths;
path one: [profile], path two: [profile, email]

DynamoDB évalue chaque action d'une UpdateExpression par rapport aux valeurs d'attributs de l'élément telles qu'elles étaient avant l'update — les actions ne sont pas appliquées l'une après l'autre de gauche à droite. Si deux actions ciblent des chemins qui se chevauchent (le même attribut, ou un parent et quelque chose d'imbriqué à l'intérieur), le résultat serait ambigu : est-ce que profile.email = :e s'exécute avant ou après que profile = :p remplace toute la map ? Plutôt que de deviner, DynamoDB rejette l'expression d'emblée. (Le même contrôle de chevauchement s'applique aux chemins en double dans une ProjectionExpression.)

Pourquoi ça arrive

  • Définir un parent et son enfant dans une seule expressionSET profile = :p, profile.email = :e. Le second chemin est à l'intérieur du premier.
  • Le même attribut apparaît deux foisSET updatedAt = :a REMOVE updatedAt, ou SET tags = :t ADD tags :more.
  • Un ODM/wrapper ajoute silencieusement un chemin que tu définis aussi — le cas classique : une bibliothèque écrit automatiquement un horodatage ou l'objet entier (SET item = :obj) pendant que ton code définit aussi item.field (vu dans Dynamoose avec les createdAt/updatedAt automatiques).
  • Mettre à jour une liste et l'un de ses éléments ensembleSET mylist = :l, mylist[0] = :v.

Comment le corriger

  1. Fonds l'enfant dans la valeur du parent — si tu remplaces la map de toute façon, mets le nouvel e-mail à l'intérieur et supprime la seconde action :

    // instead of SET profile = :p, profile.email = :e
    UpdateExpression: 'SET #p = :p',
    ExpressionAttributeValues: {':p': {name: 'Ada', email: 'ada@example.com'}}
  2. Ou mets à jour uniquement les feuilles — laisse le parent intact et définis les champs imbriqués individuellement (SET #p.#n = :n, #p.#e = :e). Les chemins frères sous le même parent ne se chevauchent pas ; seule l'imbrication le fait.

  3. Dédoublonne — assure-toi que chaque attribut apparaît dans exactement une action à travers SET/REMOVE/ADD/DELETE.

  4. Vérifie les champs automatiques de ta bibliothèque — désactive ou exclus les attributs gérés automatiquement (horodatages, versions) des updates où ta propre expression les écrit déjà.

  5. Scinde en deux requêtes quand tu as réellement besoin de la sémantique « remplacer le parent, puis ajuster l'enfant » — deux appels UpdateItem, dans l'ordre.

Éditer des maps imbriquées à la main, c'est là que les chevauchements se glissent — l'application de bureau DynoTable édite les attributs d'un élément sur place et émet un update propre et sans chevauchement pour exactement ce qui a changé.

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

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.