1

私はいくつかの奇妙な問題に遭遇しました:

私はテーブルConstrainableとテーブルを持っていますAttributeAttributeテーブル内で、外部キー制約ConstrainableAttribute属するものを指定します。テーブルCASCADE ON DELETE内のその外部キー制約にを追加しました。Attribute

今、私が削除したい場合、AttributeこれConstrainableも削除されています..これは起こってはいけませんか、それとも間違っていますか? 私はそうするためにこの方法を使用しています:

public void remove(IDBObject obj) throws DBException {
    if (manager != null) {
        IDBObject o = null;
        try {
            o = manager.getReference(obj.getClass(), obj.getPrimaryKey());
        } catch (EntityNotFoundException e) {
            throw new DBException("Entity doesnt exist");
        }
        manager.getTransaction().begin();
        manager.remove(o);
        manager.getTransaction().commit();
        return;
    }
    throw new DBException("Manager is closed or null");
}

この行動の理由は何でしょうか?

DB のより詳細な概要:

Constrainable-Table:

| | ID |

Attribute-Table:

| | ID | 制約可能な ID | 値 | <--- ここにCASCADE ON DELETE定義されている

4

2 に答える 2

2

それは不可能であり、あなたが正しく説明したように、それは起こるべきではありません。コンピューターが嘘をつくことはめったにないため、この動作を引き起こす構成に誤りがあるに違いありません。

  • 外部キーが正しく定義されていることを確認します。

    ALTER TABLE Attribute-Table ADD CONSTRAINT FK_attr_constr FOREIGN KEY (Constrainable-ID) REFERENCES Constrainable-Table (ID) ON DELETE CASCADE ON UPDATE NO ACTION;
    
  • check Constrainable-Table table はどこにも属性テーブルを参照していないか、属性を参照する可能性のある他のテーブルを参照していません。(複数の CASCADE がある場合は、それらのカスケードがスキーマを介してどのように伝播するかに注意してください)

  • 最後に ON DELETE CASCADE を削除して、同じ動作が発生するかどうかを確認します。Contrainable-table から参照された行を削除するとカスケードが発生するため、属性の削除は Constrianable-table に影響を与えないはずです。

原則として、CASCADE について 100% 確信が持てない限り、できるだけ CASCADE を使用しないでください。別の開発者が CASCADE を認識していない場合、別の作業をしているときにこの問題を発見する可能性があるからです。

于 2013-08-28T13:25:25.573 に答える
1

わかりました、私は最終的に何が起こっているのかを理解しました:

Eclipselink は、すべてForeignkey Relationship(cascade = CascadeType.ALL). クラスのカスケードを削除した後、すべてが正常に機能するはずはありません。

これは、自分でクラスを書くのが面倒な場合に起こります:PI は、クラスがこのようなエラーなしで生成されることを期待できると言うでしょう。さて、私は今私のレッスンを学びました

于 2013-08-28T14:43:56.223 に答える