3

私は 'Photo'クラスと 'Comment'クラスを持っています。写真に複数のコメントを割り当てることができます。NHibernate 1対多の削除はカスケードしない

これはHBMマッピングファイル内で1対多の関係として設定されており、Photo.hbm.xmlマッピングファイル内の「コメント」バッグに対してcascade = "all-delete-orphan"を設定しています。私はそれに関連付けられた1件の以上のコメントを持っている写真を削除しようとする場合

しかし、私は「REFERENCE制約 『FK_Comments_Photos』と競合DELETE文で」

を取得しています、私は他のカスケードのカップルを試してみました私のPhoto.hbm.xmlのコメントバッグに対するオプションですが、設定した内容に関係なく、毎回同じ結果が得られます。私はちょうど写真を削除し、関連するコメントも自動的に削除することができるようにしたい。ここで

は(簡潔にするために編集した)私の写真のマッピングである:ここで

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" .... default-access="property" default-cascade="none" default-lazy="true"> 
<class xmlns="urn:nhibernate-mapping-2.2" name="Photo" table="Photos"> 
    <id name="PhotoId" unsaved-value="0"> 
     <column name="PhotoId" /> 
     <generator class="native" /> 
    </id> 
    ... 
    <bag name="Comments" table="Comments" cascade="all-delete-orphan" order-by="DateTimePosted desc" where="Approved=1"> 
     <key column="PhotoId" /> 
     <one-to-many class="Comment" /> 
    </bag> 
</class> 

は(簡潔にするために編集した)私のコメントのマッピングです:

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" ... default-access="property" default-cascade="none" default-lazy="true"> 
<class xmlns="urn:nhibernate-mapping-2.2" name="Comment" table="Comments"> 
    <id name="CommentId" unsaved-value="0"> 
     <column name="CommentId"></column> 
     <generator class="native" /> 
    </id> 
    ... 
    <property name="Author" not-null="true" /> 
    <property name="Body" not-null="true" /> 
    <property name="Approved" not-null="true" /> 
    <many-to-one name="Photo" not-null="true"> 
     <column name="PhotoId" /> 
    </many-to-one> 
</class> 

は誰もい私が通信で写真を削除しようとしたときにカスケードが起こっていない理由について何か提案がありますそれに関連したものは?

UPDATE:私がカスケードを発生させる唯一の方法は、この関係を「カスケード」とするSQL Server内の「ルールの削除」を構成することです。これを行うと、指定する必要はありません私のNHibernateマッピング内の任意のカスケードアクション。しかし、これは私にとっては理想的ではありません - 私はNHibernateマッピング内のカスケードの動作を理想的に設定できるようにしたいのですが、なぜ私のNHibernateの通知を受けていないように見えるのか混乱していますカスケード設定?

答えて

4

私の推測では、この問題は、コメントマッピングの多対1がnot-null = "true"に設定されていることに起因すると考えられます。 そのため、NHibernateはPhotoオブジェクトを削除する前に一時的にこのプロパティをnullに設定することはできません。そのため、Photoオブジェクトを削除しようとすると、SQL Serverは外部キーの例外をスローします。

削除するときに、私はアクションの順序のための記憶が正しければ次のとおりです。すべての子を中にnullに

  1. 設定する外部キーの値が
  2. 削除親オブジェクト
  3. は、すべての子供が
を参照して削除オブジェクト

many-to-oneからnot-null = "true"を削除して、何が起こるかを確認してください。

+0

提案していただきありがとうございます。私はちょうどこれを試みたが、同じ問題/エラーメッセージ。 SQL Server内の既存のリレーションシップ/制約を削除すると、フォトレコードの削除はエラーなく行われますが、孤立した関連するコメントレコードはDBに残ります。 SQL Server内での設定方法に注意を払うだけで、SQL Server以外のカスケード設定は無視されます。 – marcusstarnes

+0

あなたは間違いなくnot-null = "true"を削除してから、Feliceが示唆したinverse = "true"を追加する必要があり、それは本当に必要で、最後にcascade = "all-delete-orphan"のままにしておきます。 NHibernateが何をする必要があるのか​​無関係であるので、私はSQLサーバを混乱させることはありません。はい、SQL Serverのカスケード削除を追加すると助けになりますが、これはエンティティマッピングファイルを適切に設定することで完全に解決できる問題です。だから私があなたの場合、私はサーバーからSQLの制約を削除し、マッピングファイルの上記の推奨事項をもう一度試してみてください。 – tolism7

+0

追加情報tolism7ありがとう。 OK、私はすべてのSQL Serverの制約を削除しました。多対1からnot-null = "true"を削除し、バッグにinverse = "true"を追加しましたが、写真を削除すると、 DB :( – marcusstarnes

2

inverse="true"あなたのマッピングのバッグコレクションでお試しください。

+0

私はまた、(それ以外は何も働いていない時に)それを試みましたが、残念なことに成功しませんでした。 – marcusstarnes

1

私は1日で同様の問題を抱えていました。

最後に、溶液をDBに沸騰させた。 私は「ルールの削除」 「INSERTのUPDATE仕様」にFKキー制約を変更する必要がありました:「アクションなし」から

「カスケード」に加えて、あなたも 「アップデートルール」を設定することができます:「アクションなし」から「カスケード」

0

あなたにはNHで削除カスケードオプションを指定することができます。

<bag name="Comments" cascade="all-delete-orphan" order-by="DateTimePosted desc" where="Approved=1"> 
    <key column="PhotoId" on-delete="cascade"/> 
    <one-to-many class="Comment" /> 
</bag> 

あなたは、おそらくそれは逆にする必要があります。次に、FK_Comments_Photos列が指定されている場所が不思議です。

関連する問題