3

ロックが必要な共有リソースを含むデータベースの更新を実行する必要があるという見解があります（実装は複雑ですが、本質的には共有カウンターにすぎません）。

競合状態から身を守るために、私はおおよそ次のようなコードを使用しています。

@transaction.commit_manually
def do_it(request):
    affected_models = Something.objects.select_for_update(blah = 1)

    for model in affected_models:
        model.modify()
        model.save()

    transaction.commit()

commit_manually、select_for_update()のこの使用法はsave()大丈夫ですか？これを確認するテストを作成するにはどうすればよいですか？たとえば、Djangoがトランザクションの間に発火するというシグナルを見つけることができません。そして、私はそれを実行することはできず、並行性の問題が発生して対処されることを願っています。

4

1 に答える 1

0

なぜそこで使わないのcommit_on_successですか？

クエリ自体は次のようになるはずです。

Something.objects.select_for_update().filter(...)

select_for_updateあなたが主張できることについて、djangoが特別なことをするとは思いません。という主張しか頭に浮かびませんassertTrue(queryset.query.select_for_update)。何もテストせず、誰かが誤って (?) 呼び出しを削除した場合にのみ役立つ可能性があります。

この実行条件の問題の単体テストを思いついたとしても、それをプロジェクトに入れるのは賢明ではないと思います。

むしろ、db の動作ではなく、コードのテストに集中してください。

于 2012-11-20T18:57:17.487 に答える