3

MySQLデータベースのオブジェクトをソフト削除し、PropelORMを使用しています。ソフト削除が機能するようになりましたが、実際の行が削除されていないため、強制された親子関係が失われます。

レコードにアクセスしたときにレコードがソフト削除されたことをPropelが認識して、null参照例外がスローされないようにする方法はありますか？このように、親は削除されましたが、その子は引き続きその関係を読み取ることができますが、子を更新するとき、または新しい子を作成するときに、削除された親にアクセスすることはできません。

例えば、

BookにはAuthorIdがあり、AuthorIdに属する作成者がソフト削除された場合、次のようになります。

$book->getAuthor();

正しい著者を返します（表示目的のみ）。ただし、新しい本が追加された場合、ソフト削除された著者は選択できません。

その機能がPropelに組み込まれているかどうか誰かが知っていますか？

4

3 に答える 3

1

ソフト削除は壊れた抽象化です。代わりにアーカイブ可能な動作を使用する必要があります（Propelブログで理由を参照してください：http：//propelorm.org/blog/2011/08/29/introducing-archivable-behavior-and-why-soft-delete-is-deprecated.html）。

于 2014-01-15T10:34:49.297 に答える
0

著者の削除が許可される理由はわかりませんが、彼の作品は削除されません（または、基本的に、これがプロジェクトのシナリオとして表示される理由）が、カスタム基準を作成して実行することはできます。次のコードは、使用しているPropelのバージョンによって異なります（ただし、概念は同じです）。

$c = new Criteria();
$c->getNewCriterion(self::AUTHOR_ID, $parentId);
return self::doSelect($c, $connection);
于 2010-11-08T22:14:04.783 に答える
0

この質問に出くわしたばかりです。説明している機能にソフト削除を使用しない方がはるかに理にかなっているようです。作成者が有効かどうかを示すフィールド、つまりisEnabledというブールフィールドを作成することを強くお勧めします。

次に、AuthorQueryクラス用に生成されたフィルターメソッドを使用できます。この場合は

AuthorQuery::create->filterByisEnabled()
                   ->find();

オブジェクトが引き続きアプリケーションで使用される場合は、削除するのは適切ではありません。ソフト削除機能は、実際には参照または元に戻すためだけのものです。

于 2013-12-23T13:54:29.493 に答える