私はしばらくの間このジレンマに悩まされていました、そして私は私がそう近づくだろうと思いました。
私のシナリオの背景：
- 0個以上のPlaylistItemの子を含むプレイリストがあります。
- プレイリストはめったに作成されません。そのため、サーバーにGUIDを要求し、応答を待ち、成功するとUIを更新して、正常に追加されたプレイリストを表示しても問題ありません。
- プレイリストアイテムオブジェクトは頻繁に作成されます。そのため、サーバーがUUIDで応答するのを待っている間、メッセージの読み込みに問題があります。
この最後の事実は最適化ですが、プログラムの使いやすさが大幅に向上すると思います。
それでも、オブジェクトをクライアント側で一意に識別するためのオプションについて説明したいと思います。最初に試したが失敗した2つのオプションを強調し、次に検討している3番目のオプションを強調します。他の可能な解決策についての洞察が欲しいです。
サーバーに永続化されるPKUUIDクライアント側を生成します。
これが私の最初の選択でした。それは明らかな決定でしたが、いくつかの明らかな欠点があります。ここでの最初の問題は、クライアント側のUUIDは、この種の目的では信頼できないし、信頼すべきではないということです。悪意のあるユーザーは、PKの衝突を簡単に強制できます。さらに、クライアント側でUUIDを生成することを選択した場合、衝突の可能性が高くなることを期待する必要があることを理解しています。それを傷つけます。
プレイリストGUIDとプレイリスト内の位置に基づいて複合PKを生成します
これはトリッキーですが、私の問題に対する素晴らしい解決策だと思いました。プレイリストアイテムの位置は、特定のプレイリストコレクションに固有であり、クライアント側とサーバー側の両方で導出できます。これは素晴らしい修正のようでした。残念ながら、私の立場をPKの一部にすることは、私のPKの不変性を壊します。プレイリストアイテムを並べ替えたり削除したりするたびに、大量のプレイリストアイテムキーを更新する必要があります。それを傷つけます。
プレイリストGUIDと自動インクリメントプレイリストアイテムIDに基づいて複合PKを生成する
このソリューションは上記のソリューションと似ていますが、複合キーを位置から分離することにより、PKが不変であることを保証します。これは私がいじっている現在の解決策です。私の唯一の懸念は、悪意のあるユーザーが送信する前にクライアントの自動インクリメントIDを変更することで衝突を強制する可能性があることです。このような悪意のある行為がシステムに害を及ぼすとは思いませんが、考慮すべきことがあります。
わかった！そこにあります。私はこれらすべてを行うのに愚かですか？それを吸い上げて、サーバーにPlaylistItemオブジェクトのGUIDを生成させるだけですか？または、適切な実装を作成することは可能ですか？
アップデート：
サーバーがデータベースに正常に保存される前にユーザーのアクションを視覚的に表現し、保存が失敗した場合に必要な回復手法を実装したいと考えています。これがばかげているかどうかはわかりませんが、ユースケースのシナリオを通じて私の理由を説明します。
クライアントが新しいPlaylistItemを追加したいと考えています。そのために、PlaylistItemを作成するために必要なすべての情報をYouTubeのAPIにリクエストします。クライアントは、YouTubeのAPIが応答した後にPlaylistItemを作成するために必要なすべての情報を持っています。ただし、それを一意に識別する機能は除きます。
この時点で、ユーザーはすでにYouTubeのAPIをX時間待っています。ここで、クライアントにPlaylistItemを視覚的に表示したいと思います。サーバーを待つことを選択した場合、成功の視覚的な兆候が現れる前に、X+Yの時間枠を待っています。テストでは、この遅延は厄介だと感じました。
私のサーバーは、AmazonのEC2上の単なるマイクロインスタンスです。ハードウェアをアップグレードすることでYの時間枠を短縮できましたが、巧妙なプログラミングでYを完全に排除できました。これが私が直面しているジレンマです。