dbcontext SaveChangesステートメント実行の順序

Question

順序列のあるテーブルに一意のインデックスがあるテーブルがあります。たとえば、テーブルには次の列があります。

TableId、id1、id2、ordinal

一意のインデックスは、列id1、id2、ordinal全体にあります。

私が抱えている問題は、データベースからレコードを削除したときに、再び順番に順番になるように序数を再等しくすることです。私の削除関数は次のようになります：

    public void Delete(int id)
    {
        var tableObject = Context.TableObject.Find(id);
        Context.TableObject.Remove(tableObject);
        ResequenceOrdinalsAfterDelete(tableObject);
    }

問題は、Context.saveChanges（）を呼び出すと、ステートメントが渡されたのとは異なる順序でステートメントを実行するように見えるため、一意のインデックスを破ることです。たとえば、次のことが起こります。

1. 条例を控除します
2. レコードを削除します

それ以外の：

1. レコードを削除します
2. 条例を控除します

これはEFの正しい動作ですか？もしそうなら、この動作を無効にして実行の順序を強制する方法はありますか？

これを適切に説明していない場合は、お知らせください...

Answer 1

コマンドの順序は、EFの完全に制御されています。注文に影響を与える唯一の方法は、すべての操作に個別のSaveChangesを使用することです。

public void Delete(int id)
{
    var tableObject = Context.TableObject.Find(id);
    Context.TableObject.Remove(tableObject);
    Context.SaveChanges();
    ResequenceOrdinalsAfterDelete(tableObject);
    Context.SaveChanges();
}

また、そのコードを手動で作成したトランザクションで実行して、Atomicityを確保する必要があります（=> TransactionScope).

ただし、最良の解決策は、おそらく、影響を受けたすべてのレコードをデータベースからアプリケーションに引き込み、序数を変更し、データベースに1つずつ保存する必要があるため、おそらくストアドプロシージャを使用することです。

ところで。データベースの匂いでこれを行う。 「序数」シーケンスにギャップがあることの問題は何ですか？