新しいエンティティを作成すると、IDシーケンスが1001、2002、3003のようになり、1003のようなルールがない場合があるという問題があります。
次のような各テーブルのシーケンスを作成したいと思います：1、2、3、4、5、...
問題は新しい1.9.0.0S＃arpプロジェクトから始まったと思います。1.6.0.0から開発中のプロジェクト、または1.6.0.0から開始して1.9.0.0に変換されたプロジェクトは問題なく、シーケンスは良好です。
どこが問題になるか知っていますか？
どこかで何かおかしなことをしなければならないのですが、S＃arpがわからないので、どこが問題になるのかわかりません。
見た目からすると、IDは現在POIDジェネレーターを使用して生成されているようです。これについては、次の投稿ですべて読むことができます：http: //nhforge.org/blogs/nhibernate/archive/2009/03/20 /nhibernate-poid-generators-revealed.aspx
これで、提供したIDから、HiLoジェネレーターを使用しているように見えます。その概要を確認するために、各sessionFactoryは、割り当て可能なIDの予約済みセット（定義可能）を保持します。すべてのIDを実行すると、新しいセットが取得され、次の高い値が同じdBのテーブルに格納されます。したがって、sessionFactoryを再作成するたびに新しいセットが取得されるため、IDの増分がこの値が1000の場合..シャープアーキテクチャウィキでこれへの参照を見つけました：https ：//github.com/sharparchitecture/Sharp-Architecture/wiki/HiLoGeneratorそして彼らがそれを1000に設定したように見えます。
私はあなたが同様の慣習を定義していると推測しています、そしてそれがあなたがこれを見ている理由です。
素敵なシーケンスが必要な場合は、Id戦略をアイデンティティに変更することをお勧めします。ただし、これらのタイプのジェネレーターには、作業単位戦略のバッチ処理や中断ができないなどの欠点があります。
ご指摘のとおり、s＃arpは、HILO上記の欠点に悩まされない戦略を使用しています。ただし、1つの欠点（実際には欠点ではありません）は、セッションファクトリが構築されるたびにテーブルからId's新しいものが取得されるため、シーケンシャルではないことです（1001、1002、2001、2002、3003など） 。これは、プロジェクトを何度もビルドするときに、開発マシンでより明確になります。本番サーバーでは、セッションファクトリの再構築が少ないため、ギャップは少なくなります。また、ギャップを減らすのではなく、loを減らすことができます！HIhilo10100
IMO結局のところ、内部IDは内部の権利であるため、内部IDが連続していることは問題ではありませんか？また、レコードを削除すると、とにかくギャップが表示されます。
テーブルidがビジネスロジックに依存している場合、内部id'sは答えではなく、内部IDと、ビジネスロジックに固有のインデックスを持つ列が必要になる場合がありますId。
シーケンシャル内部IDが重要だと思う理由を自問しますか？うまくいけば、あなたはそれを心配するほど実際には重要ではないことに気付くでしょう。