問題タブ [rowversion]

私はMVC3アプリケーションに取り組んでいます。クライアント側のViewModelには、byte[]であるSQLServerRowVersionプロパティが含まれています。クライアント側でオブジェクト配列としてレンダリングされます。ビューモデルをコントローラーに投稿しようとすると、RowVersionプロパティは常にnullになります。

Controllerシリアライザー（JsonValueProviderFactory）がObject配列プロパティを無視していると想定しています。

私はこのブログを見ましたが、フォームのマークアップではなくJSONを投稿しているため、これは当てはまりません：http: //thedatafarm.com/blog/data-access/round-tripping-a-timestamp-field-with-ef4 -1-code-first-and-mvc-3 /

私のビューは私のビューモデルを次のようにレンダリングします：

次に、viewModelを次のようにコントローラーに投稿します。

これがコントローラーでの私のアクションです：

更新：ダリンの答えに基づいています。

よりクリーンなソリューションを望んでいましたが、Darinが唯一の答えを提供したので、byte[]"row_version"プロパティをBase64文字列にシリアル化するカスタムプロパティを追加する必要があります。また、Base64文字列が新しいカスタムプロパティに設定されると、文字列がbyte[]に変換されます。以下は、モデルに追加したカスタムの「RowVersion」プロパティです。

RowVersion列とBinary（8）列を使用して、行が変更されたかどうかを追跡している状況があります。

理想的にはいつでも：

その後、その記録に変更がありました。これに関する本当の問題は、2つの列を等しく設定するための適切な方法が見つからないことです。Binaryフィールドを更新すると、更新クエリはそのレコードのRowVersionフィールドをインクリメントします。Binaryフィールドを楽観的にインクリメントすることに混乱しましたが、ほとんど機能します。重要なのは、UPDATEクエリが影響を与えるレコードの総数だけBinaryフィールドをインクリメントする必要があるということです。行バージョンを一時停止する方法、または更新ステートメントの値を使用するために更新ステートメントの最後に何が表示されるかを決定する方法についてのアイデアはありますか？

わかりやすくするために、2つのフィールドを一致させるために機能する例を次に示します。

これらのテーブルの変更を追跡するために、DB rowversion のほとんどのテーブルに追加する予定です。追加するとクエリのパフォーマンスに影響することはわかっています。

それがパフォーマンスに少し影響するか (数パーセント遅くなるか)、DB の速度が大幅に低下するため、多くのテーブルに rowversion を追加するべきではないかどうかは誰にもわかりません。

LINQ to SQLでかなりうまく機能したものが、Entity Frameworkでは非常に鈍感（または不可能）に見える場合があります。rowversion具体的には、プロパティ（バージョン管理と同時実行制御の両方）を含むエンティティがあります。何かのようなもの：

エンティティを入力として受け取り、最近更新された他のすべてのエンティティを見つけられるようにしたいと思います。何かのようなもの：

これで、データベースでこれが機能します。2つのrowversion値を問題なく相互に比較できます。また、LINQ to SQLを使用する前に同様のことを行いました。これにより、をにマップrowversionしSystem.Data.Linq.Binary、比較することができます。（少なくとも、式ツリーをデータベースにマップして戻すことができる範囲で。）

ただし、Code Firstでは、プロパティのタイプはである必要がありますbyte[]。また、2つの配列を通常の比較演算子と比較することはできません。LINQ to Entitiesが理解する配列の比較を書く他の方法はありますか？または、配列を他の型に強制変換して、比較がコンパイラーを通過できるようにしますか？

ストレージ モデルで SQL Server の rowversion フィールドを宣言し、Entity Framework で既定のマッピングを行うと、rowversion フィールドがバイト配列にマップされます。

それをより使いやすい型にマップすることは可能ですか (これにより、.NET 側から等値演算子と比較演算子を表現できるようになります)? rowversion の基になる型が binary(8) であることを考えると、それを 64 ビット整数にマップできる可能性があると思います。

現在使用されているプロパティ定義は次のとおりです。

SSDL:

CSDL:

次のように.NETで結果を取得します。

結果はバイト配列[0]= 0,[1]=0,[2]=0,[3]=0,[4]=0,[5]=0,[6]=30,[7]=138ですが、SQL Server での結果は0x0000000000001E8A.

"0x0000000000001E8A".NETで値を取得するにはどうすればよいですか?

私はC＃、EF、SQL Serverを使用しており、親子関係のあるテーブルがいくつかあります。2つ以上ありますが、この例では、簡単にするために2つだけを使用します。

テーブルブック

テーブルページ

1つまたは複数のページが更新されたらDateModified、ブックテーブルで更新する必要があります。

変更を追跡するために使用しています。これは、次のような操作RowVersionを行うだけで、各本の最新の変更を常に取得できるようにしたいという独自の価値があるためです。

RowVersionただし、これを行うには、 inテーブルが常にinの前にBook更新されていることを確認する必要があります。RowVersionsPages

私のEDMレイヤーには、現在次のようなものがあります。

これを行うと、ページが最初に更新され、トランザクションがコミットされた後、そのRowVersionも最初に更新されます。それは私が必要としているものではありません。

質問、代わりにイベントOnPageChanged()を処理するように移動する場合OnPropertyChanging、これにより一貫性が保証されますか？EFによって生成されたSQLで更新が行われる順序を決定するのはそれOnPropertyChangedですか？この場合の他の提案はありますか？

SQL Server データベースの一部のテーブルにデータの同時実行を適用したいと考えています。行のバージョン管理を実現するために、integerという名前の列を追加RowVersionし、行を更新するときに列の行の値を増やすことを考えています。

別のオプションがあります:timestamp列を使用します。timestamp列を使用すると、SQL Server は行が更新されたときに一意の値を自動的に作成します。

これらのオプションの利点を知りたいです。int列を挿入して行バージョンを格納するのはより一般的な方法ですが、timestamp列を挿入するのはSQL Server固有のものだと思います。

さらに、integer行バージョンの値は、列よりも読みやすいですtimestamp。

integer行バージョン フィールドの列を選択するその他の利点または欠点を知りたいです。

ありがとう。

rowversionMicrosoft SQL Server 2008 R2 で有効なデータ型ではありませんか?

ボーナスおしゃべり

rowversionテーブルに列を追加しようとしています:

しかし、「データ型」列を離れようとすると、SQL Server Management Studio が文句を言います

データ型が無効です。

そして、別のデータ型を選択することを主張します:

が有効なデータ型でないrowversion場合に列を作成するにはどうすればよいですか?rowversion

ボーナス視聴

ボーナスリーディング

行バージョン (Transact-SQL)

タイムスタンプは、rowversionデータ型のシノニムであり、データ型シノニムの動作に従います。DDL ステートメントでは、可能な限りタイムスタンプの代わりにrowversionを使用します。詳細については、「 データ型の同義語 (Transact-SQL) 」を参照してください。

タイムスタンプ構文は非推奨です。この機能は、Microsoft SQL Server の将来のバージョンでは削除される予定です。新しい開発作業でこの機能を使用することは避け、現在この機能を使用しているアプリケーションを変更することを計画してください。

追加ボーナスおしゃべり

私の質問はこの質問と同じですが、少し追加します。私の問題は、Web アプリのユーザーが新しいバージョンのレコードを作成できることです。レコードのすべての新しいバージョンは、その特定のバージョンへの個々の変更を記録するために、50 の他の関連テーブルに対応する「新しいバージョン」を作成することになります。関連する約 50 のテーブルを含むこの新しいバージョンの作成は、トランザクション内で実行されます (エラーが発生した場合にすべての変更をロールバックするため)。多くの場合、この手順は遅くなります。当然のことながら、テーブルの「挿入」が多すぎる「長いトランザクション」が原因です。

このようなシナリオを実装するためのより良いソリューション/設計を検討しています。

1. 特に複数のテーブルであまりにも多くの重複を作成する場合、同じレコードの「バージョン」を維持するためのより良い方法はありますか?
2. 「すべての行バージョン」に挿入されるレコードが多すぎるため、設計自体は良いとは思いませんが、少なくとも差し迫った問題である「長いトランザクション」に対処したいと思います-これは時々遅延を引き起こします. 抜け道はないかもしれませんが、それでも質問したい - 「バージョン管理」をトランザクション内に配置しない場合、エラーが発生した場合にロールバックするより良い方法はありますか (トランザクションが他の OLTP をブロックしているように見えるため)クエリ - すべてのプライマリ テーブルに新しいバージョンを挿入するため)

バージョン管理クエリは現在約 10 秒間実行されますが、時々悪化します。どんな考えでも大歓迎です