問題タブ [django-reversion]

最近、モデルの変更履歴を保持するために、プロジェクトにdjango-reversionを追加しました。現在、システムにモデルを保存するたびに、ログに次の警告が表示されます。

.../site-packages/reversion/models.py:218: UserWarning: pre_save および post_save シグナルは、django-reversion 1.8 のリビジョンおよびバージョン モデルに対して送信されなくなりました。代わりに pre_revision_commit および post_revision_commit シグナルを使用してください。

ただし、リビジョン モデルとバージョン モデル自体で pre_save 信号と post_save 信号を使用していないか、それらを拡張するものは使用していません。バージョン管理??

django admin でモデルのバージョン管理を追加する必要があるため、ここから django- reversion をインストールしました。サーバーにインターネット接続がないため、pip を使用できませんでした。zip を手動でダウンロードする必要がありました。ファイルを github からダウンロードし、サーバーにアップロードし、コンテンツを抽出して実行python setup.py installし、復元をインストールします。

ただし、インポートしようとすると、次のエラーが発生します。

github ページによると、現在の復帰バージョンは 1.8.0 であり、django 1.6 と互換性があるはずです。何が問題なのですか?

私は、django-reversion を使用して変更を追跡し、以前の状態に戻す機能を提供するプロジェクトに取り組んでおり、一部のツリー型モデルには django-mptt を使用しています。ただし、削除および元に戻す機能には、いくつかの奇妙な動作があります。次のようなデモ データを使用しています。

ノードを削除するとそのすべてのサブノードもリビジョンに保存されるように、django-reversion をリグしました。そのため、Big Company を削除するとツリー全体が削除され、それを元に戻す (または実際にはサブノードのいずれか) も元に戻ります木全体。ここまでは順調ですね。

ただし、サブノードを削除/元に戻そうとすると、事態が奇妙になり始めます。たとえば、「サブ会社 1」を削除すると、「サブ会社 2」とその子孫がテンプレートでのレンダリングを停止します (ただし、この動作は奇妙なことに、多少一貫性がありません)。または、django-reversion を使用して削除後に 'Sub Company 2' を復元する必要がありますが、'Tiny Companies' はテンプレートでレンダリングされません (ただし、オブジェクトをすばやくダッキングしshellて呼び出すと、オブジェクトがまだデータベースにあることが示されます。彼らはまだ親として 'Sub Company 2' を持っています。

これらの問題はすべてCompany.objects.rebuild()、ツリーを適切な表現に復元する を呼び出すことで修正できますが、このプロジェクトの本番対応バージョンでは、データベースに大量のデータが含まれている可能性があり、それはテーブル全体のアクティビティであるため、非常に困難です。高い。この問題を解決するために何ができるかについてのアイデアはありますか?

同じモデルで Django Reversion と Django-Import-Export を有効にしようとしています...ロジックが正しいかどうか、または複数の admin.py ファイルを使用する必要があるかどうかなどはわかりません

私は次のことを試しましたが、これはDjango Reversionのみが機能することを可能にします.Import Export Worksを切り替えると. 両方を同時に有効にできたら最高です。

私は両方のプロジェクトの readthedocs を見てきましたが、まだ迷っています。

http://django-reversion.readthedocs.org/en/latest/admin.html#admin https://django-import-export.readthedocs.org/en/latest/getting_started.html

乾杯 xc0m

django-revisions で遊んでいるとき、いくつかの初期テストを作成しています。一部の API とビュー コードがリビジョンを正しく保存することをテストできるようにしたいと考えています。ただし、削除されたバージョンを保存するための基本的なテストすら取得できません。

削除された QuerySet の長さを次のようにチェックすると、これは失敗します。

私の仮説は、モデルの最初のリビジョンを作成する必要があるというものです ( と同等のことを行います./manage.py createinitialrevisions)。これが問題である場合、テストで最初のリビジョンを作成するにはどうすればよいですか? それが問題でない場合、他に何を試すことができますか?

私は DJANGO バックエンドに取り組んできましたが、その主なユースケースは、特定の一連の画像を関連するタグとともに保存する機能です。

現在の設計では、新しいセットを作成し、特定のセットに画像を追加し、特定のセットにタグを関連付けるための専用の REST-ful API を想定しています。これにより、個別のクライアント呼び出しが発生します。

例えば ​​：

「新しいセットの作成」トランザクションを開始します

1. 新しいセットを作成し、セット ID を受け取る
2. セットの最初の写真をアップロードする
3. セットの 2 番目の写真をアップロードします (合計写真数に応じて...)
4. この新しく追加されたセットに関連するタグを追加します

取引を終了する

異なる HTTP リクエスト間で分割されていることを認識して、そのようなトランザクションをコミット/ロールバックするにはどうすればよいですか?

ここで設計上の問題がありますか? 単一の累積的な HTTP リクエスト アプローチを支持しますか?

このようなバックエンドは、一時的な信号損失が発生する可能性があるモバイル デバイスで使用されることを考慮してください。

どんなアドバイスでも大歓迎です。

アップデート：

問題を解決するために、django-revisions などのモデルのバージョン管理パッケージを使用すると便利でしょうか?

最後の POST/PUt/DELETE またはデータベース内のあらゆる種類のトランザクションを元に戻したいです。Django-reversionについて読み、実装してみました。しかし、運が悪かった。これが私のコードです。私が何をしているのか確認してください!!!

反転するモデル:-

ビュー

私は何を間違っていますか??