問題タブ [deferrable-constraint]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
oracle - 一意の制約違反を回避するために、INSERT の前に Hibernate に DELETE を強制的に発行させますか?
背景: http://jeffkemponoracle.com/2011/03/11/handling-unique-constraint-violations-by-hibernate
私たちのテーブルは次のとおりです。
BOND_PAYMENT_ID には主キー制約があり、(BOND_NUMBER, PAYMENT_ID) には一意の制約があります。
アプリケーションは Hibernate を使用し、ユーザーは特定の債券にリンクされたすべての支払いを表示できます。また、新しいリンクを作成したり、既存のリンクを削除したりできます。ページに必要な変更をすべて加えたら、[保存] をクリックすると、Hibernate が魔法のようにデータベースで必要な SQL を実行します。どうやら、Hibernate はどのレコードを削除する必要があるか、どのレコードを挿入する必要があるかを判断し、残りはそのままにしておきます。残念ながら、最初に INSERT を実行し、次に DELETE を実行します。
ユーザーが支払いへのリンクを削除し、気が変わって同じ支払いへのリンクを再挿入した場合、Hibernate は喜んでリンクを挿入してから削除しようとします。これらの挿入/削除は別個の SQL ステートメントとして実行されるため、Oracle は最初の挿入時にすぐに制約を検証し、ORA-00001 一意の制約違反を発行します。
私たちが知っているのは次の 2 つのオプションだけです。
- 制約を延期可能にする
- 一意の制約を削除します
オプション 2 はあまり好ましくありません。これは、制約によって、一貫性のないデータが保存される可能性がある厄介なアプリケーションのバグから優れた保護が提供されるためです。オプション1を使用しました。
欠点は、この制約をポリシングするために作成されたインデックスが一意ではないインデックスになったため、クエリの効率が多少低下する可能性があることです。これは、この特定のケースではそれほど大きな不利益ではないと判断しました。もう 1 つの欠点 (Gary のアドバイス) は、特定の Oracle バグに悩まされる可能性があることです。ただし、アプリケーションの動作方法により、(少なくとも、ほとんど) 免疫があると思います。
他に考慮すべきオプションはありますか？
sql - postgresqlで最初に延期された延期可能
私は2つのテーブルに循環外部キーを持っているので、以下のように最初に延期された延期可能を使用します:
ここまでは順調ですね。しかし、テーブルに挿入したいとき、最初に遅延可能を指定したにもかかわらず、外部キー違反が発生します。
どうしたの？
sql - PostgreSQL の延期可能なチェック制約
次のように、必須の参加をチェックする機能があります。
次に、CHECK 制約から呼び出されます
標準 SQL で遅延可能な制約を作成するには、次のようにします。
PostgreSQL で同じことを行うにはどうすればよいですか?
ruby-on-rails - Rails Minitest では、テストはどのようにパスし、再テストすると失敗するのでしょうか?
Minitest でトランザクション フィクスチャを使用しています。最初にテストを実行すると、テストは正常に実行されます (そして合格します)。
ただし、すぐにもう一度実行すると、失敗します。
テーブルに外部キーを追加するためにschema_plus gem を使用しています。
フィクスチャはアルファベット順にロードされるためdeferrable: :initially_deferred、トランザクションの最後に参照整合性チェックのみを行うオプションを使用しているため、チェックの前にすべてのデータがすべてのテーブルにロードされます。これが、テストの最初の実行を機能させた理由です...しかし、2回目の実行でなぜ異なるのかはわかりません.
再テストを実行するとき、すべてのデータベース テーブルを空にし、据え置き可能オプションを使用してフィクスチャをリロードするべきではありませんか? それは、最初の後に遅延可能が尊重されないようです。
それを機能させるにはrake db:reset、実行中のテストの間に常に実行する必要がありますが、これはクレイジーに思えます。
更新 1:callsのすべてのフィクスチャ(実際には のテストとは関係ありません)をコメントアウトするとnumber_test.rb、すべて正常に動作します... 数値テストを何度でも再実行でき、それでも合格します。だから、それは延期と何かのようです。
postgresql - 通常の外部キー制約が延期できないのはなぜですか?
外部キー制約を持つ 2 つの単純なテーブルがあります。
トランザクションの期間中、制約を延期したい
次のエラーが表示されます。
私はpostgresのSET CONSTRAINTSドキュメントを読んでいますが、なぜこの制約が延期される資格がないのか理解できません:
現在、この設定の影響を受けるのは、UNIQUE、PRIMARY KEY、REFERENCES (外部キー)、および EXCLUDE 制約のみです。NOT NULL および CHECK 制約は、行が挿入または変更されるとすぐに (ステートメントの最後ではなく) 常にチェックされます。DEFERRABLE と宣言されていない一意性と除外制約もすぐにチェックされます。
ドキュメントから何か不足していますか？