送信前にDynamoDBマップの更新パスを確認する必要があります

Question

データをDynamoDBにマップ属性タイプとして格納し、そのデータを修正するための安らかなPATCHエンドポイントを実装しています（RFC 6902）。

私の検証ルーチンでは、パッチを更新式に変換してDynamoDBに送る前に、マップの存在を確認していません。

これは、マップがDynamoDBにまだ設定されていないと、更新が失敗することを意味します（ドキュメントパスが存在しないため、ValidationExceptionが発生します）。

私の質問：DynamoDBがこのような方法でアップデートを拒否することに頼っているのですか、アイテムのコピーを手に入れて、自分の検証ルーチンでパッチを拒絶すべきですか？

DynamoDBにパッチを拒否する喜びを与えない（それは私にGET呼び出しを保存する）という理由を考えることができませんでしたが、このようなサードパーティの検証に頼るのはちょっと神経質になります（AWSにアクセスする際にAWSにアクセスする際のAPIバージョンを指定していますが、これは常に有効です）

Answer 1

これは非常に主観的な質問のようですが、個人的にはDynamoDBへの余分なラウンドトリップは、それが見える方法では、DynamoDBに続く更新が発生する最悪の場合です。これは、成功を成功として返すローカルデータベース更新を処理することと変わりありません。

長期的な下位互換性（DynamoDB API契約があなたの下から変更されていること）を心配している場合は、ソフトウェア依存性を更新するたびに定期的かつ具体的に実行されるいくつかの機能/ 。

Answer 2

一般的に2つのカテゴリのいずれかに該当します。ディープ・パスの更新（中間のマップ/リスト・レベルが存在することを事前に知る必要がある場合）。あなたが行って新しいノードを作成するフリースタイルのアップデート

私は同様の問題があったので、このnpmモジュールを作成しました（免責事項：私は両方のシナリオをカバーしています）。深いパスの更新の場合は、孤児を真に設定します。代わりにorphansをfalse（デフォルト）に設定します。ここでは、更新に既存のノードのパスが含まれ、ネストされたJSONに値を新しい値で設定します。

オリジナルと更新されたドキュメントの差分動作と更新式の自動生成を使用します。ビジネスニーズに応じて、孤児を真偽に設定することができます。