2011-08-06 13 views
4

私が働いている会社のプロジェクト/タスクトラッカーとして、内部的に使用するためのアプリケーションがあります。 MongoDB atmで遊ぶ。私は以下の擬似スキーマを念頭に置いています:Python + MongoDBドキュメントのバージョン管理

task 
    _id 
    name 
    project 
    initial_notes 
    versions 
     number 
     versions 
      version_1 
       worker 
       status 
       date(if submitted) 
       review_notes(if rejected) 
       reply_on(if accepted/rejected) 
      (version_n)(if any) 

問題は私がタスクをバージョン管理することです。私は可能な方法の数を読んだが、私はそれらをすべて理解することが不足している。私はhereを気に入って何かを読んで、本当にmongoidが行う方法のように、それはより良い私はむしろそれを持っているだろう、私は最新バージョンのみを表示したいと思い、この

task 
    _id 
    versions 
     number_of_versions: 3 
     current_version 
      version_no: 3 
      worker: bob 
      status: accepted 
     old_versions 
      version 
       version_no: 2 
       worker: bob 

のようなもの、それのversioning

思考です特定のタスクの詳細情報ページを入力するときに、特定のタスクのすべてのバージョンを表示したいと考えています。この構造は機能するだろうか?はいの場合、必要なものを達成するために実行する必要があるクエリは何でしょうか?

これを読んでいただきありがとうございました。ありがとうございます。 ステータスは: バージョン version_noを拒否:1 労働者:スミス ステータス:拒否

答えて

4

はい、理由はありません。その仕組みはうまくいくでしょう。また、あなたはこのようなものが考えられます:

task 
    ... 
    versions = [  # MongoDB array 
     { version_id 
      worker 
      status 
      date(if submitted) 
      review_notes(if rejected) 
      reply_on(if accepted/rejected) 
     }, 
     { version_id : ... }, 
     ... 

可能性のあるバージョンの挿入クエリ:

tasks.update({ # a query to locate a particular task}, 
       { '$push' : { 'versions', { # new version } } }) 

注、この場合のバージョンの配列から最後のバージョンを取得ないことで、プログラムによって行われていることモンゴ

+0

このように配列全体を取り出し、それをループして最新のものを決定して表示しますか?他のスキーマよりも利点がありますか?最初のバージョンでは、db.task.findOne({}、名前:1、...、versions.current_version:1)多数のタスクが正しいでしょうか? dbがそれほど大きくないと考えるとアクセス時間に問題はありませんが、私はこのパターンをより大きなスケール(別のアプリケーション)に適用する必要がある場合、将来の参照を求めています – pocorschi

+0

バージョンあたりの急速な成長すべてのタスクでは、バージョンを別のコレクションに保持する必要があります。それは "SQLのやり方"と同じように聞こえるかもしれませんが、それはMongo DBのドキュメントによって奨励されています:http://www.mongodb.org/display/DOCS/Schema+Design#SchemaDesign-UseCases –

+0

バージョンは5-6の範囲になければなりません最大。まだ私は自分のやり方や提案と一緒に行かなければならないかどうかは分かりません。そこに微妙な違いがありますが、私はそれが肯定的か否定的かを見ることができません – pocorschi

3

また、このようなモデルを検討できます。これは、あなたの現在のデータはトップレベルに常にあるという利点を持っている

task 
    _id 
    ... 
    old_versions [ 
     { 
      retired_on 
      retired_by 
      ... 
     } 
    ] 

を(明示的に現在のバージョンを追跡する必要はありません、ドキュメントがあります現在のバージョンを取得し、old_versionsフィールドを削除し、$pushをdbのold_versionsフィールドに追加することで、履歴を簡単に追跡できます。

あなたがネットワークIOを最小限にしたいように見えたので、これはまた、あなたがそれらを必要としないときに簡単にold_versionsをロード避けることができます:

> db.tasks.find({...}, {old_versions: 0}) 

また手の込んだ取得し、旧バージョンのリストを格納することができ変更されたフィールドだけが表示されます。これには、アプリケーション層でより繊細なコードが必要であり、多くのリビジョンが期待できない場合や、これらのドキュメントが非常に大きい場合は必要ない場合があります。

関連する問題