バージョンスタックの管理
バージョンスタックの管理
バージョンスタックの管理
バージョンスタックは、Frame.io の整理原則であり、アセットをフォルダーに配置せずに縦に「スタック」できるようにします。スタックされたバージョンにより、Frame.io UI 内でのアセット間のナビゲーションが容易になり、左右に並べたレビューがサポートされます。
スタックへの直接のアップロードは現在、サポートしていないので、基本的なバージョンスタックワークフローを管理するための API シーケンスは、Frame.io UI と同じシーケンスに従います。
既存のバージョンスタックの順序を変更したり、個々のバージョンをスタックからノックアウトしたりできます。最後に、バージョンスタックは、構成アセットを削除せずに削除できます。
バージョンスタックの最上位レベルには、必ず cover_asset_id という属性があります。これは、Frame.io web UI にサムネイルが表示されているアセットの id であり、スタック内で最も大きい番号のバージョンです。
バージョンスタック - フォルダーと同様 - アセットの特別な types です。同じエンドポイントでこれを取得し、API 応答の type キーの値に基づいて解析し、それに応じてルーティングできます。これは、実際には一般的に簡単ですが、大規模なスタックを管理する場合は、いくつかの問題点を提示する可能性があります。
バージョンスタックを操作するための鍵は、最も一般的な 4 つのシナリオを分離することです。
id のスタックが作成されます。最初の 2 つのシナリオでは、同じエンドポイント呼び出しを使用するため、唯一の本当の微妙な違いは、(2 つのアセットから)新しいスタックを作成するか、アセットを既存のスタックに追加するかを知ることです。それとは別に、制約は、次のように予測可能です。
asset_type で一致する必要があります(例えば、画像をストリームにスタッキングすることはできません)。 ** **後者の 2 つのシナリオも非常に単純ですが、スタック自体についてもう少し詳しく知る必要があります。例えば、スタック内のアセットを並べ替えるには、ターゲットアセットを配置する場所の両側にあるアセットの id がわかっている必要があります。これは一般的に、スタック全体を既に取得していることを意味します。
このガイドを開始する前に、次のスコープを含むトークンがあることを確認する必要があります。
最初のステップは、2 つの重要なシナリオ(アセットを別のアセットに追加してスタックを作成するか、アセットをスタックに追加してそのスタックを拡張するか)のうち、いずれのシナリオにいるかを特定することです。
バージョン管理されていないアセットを操作することがわかっている場合、またはバージョンスタック id が既にある場合は、ステップ 2 に移ることができます。
そうでない場合、宛先アセットが既にスタックの一部であるかどうかを判断する最も簡単な方法は、次のとおりです。
/v2/assets/:id への呼び出しを介して、ターゲットアセットを GET しますtype を確認します。type が file の場合は、parent_id を取得します **type を確認します。親の type が version_stack の場合は、その id を宛先として使用します。 **
type がそれ以外の場合は、通常のアセットを取り扱っており、元の id を宛先として使用できます。
宛先 uuid がわかったので、スタックに追加するアセットの uuid を知る必要があります。
id を知る必要があります。バージョンスタック追加に必要な本文パラメーターは、next_asset_id です。
両方のアセット id パラメーターがわかったので、/assets/:id/version に POST する準備ができました。ここで、:id は宛先アセットまたはバージョンスタックであり、ソース(新しい)アセットは本文ペイロードにあります。
バージョンスタックは、各アセットが next_asset_id および prev_asset_id 近傍にあるというシンプルな序数概念に依存しています。この順序は、バージョン番号付けではなく、各アセットの index 属性を参照しています。index は、バージョン番号とは逆に進むので、次のようになります。
prev アセットはありますが、next アセットはありませんnext アセットはありますが、 prev アセットはありませんprev および next アセットがあります。これらはそれぞれ、より高いバージョン ID を持つアセット、より低いバージョン ID を持つアセットです。これにより、次の 3 つの異なるシナリオが得られます。これらはすべて、同じエンドポイント呼び出しに依存します。
呼び出し:
本文:
いずれの場合も、URL パスの id は、移動するアセットになります。
アセットは、バージョンスタックに移動されると、スタック自体の子になります。アセットをバージョンスタックから移動するには、スタックの格納フォルダーに実質的に再親化することが必要になります。
/v2/assets/:id への呼び出しを介してバージョンスタック自体を GETparent_id を取得します(これが、新しいターゲットフォルダー id になります)。呼び出し:
本文:
バージョンスタックの削除は、非常に簡単です。
これで完了です。スタックを削除すると、そのすべての構成アセットがスタックの格納フォルダーに返されます。
バージョンスタックからすべての要素を削除すると、要素が 1 個のバージョンスタックになります。これは簡単に見つけることができます。id を使用してバージョンスタックを GET すると、"version": 1 属性を持っていることがわかります。
これは技術的には問題ありません。シングルトンバージョンが読み込まれて再生され、新しいバージョンを追加でき、すべてが普通に実行されますが、Frame.io の web アプリケーションやその他のアプリケーションでユーザーに混乱を招くシナリオを示さないよう、シングルトンスタックは削除することをお勧めします。
バージョンスタッキングエンドポイントについて詳しくは アセットドキュメントを参照してください。