1

Message のキーの db.ListProperty によって関連付けられた、Message と Contact の 2 種類があるとします。ユーザーがメッセージを作成し、いくつかの連絡先を受信者として追加し、メッセージを電子メールで送信します。その後、ユーザーは、メッセージの受信者であった連絡先エンティティの 1 つを削除します。アプリケーションは適切な連絡先エンティティを削除する必要がありますが、ユーザーの記録のために送信されたメッセージの元の受信者リストを保持したいと考えています。要するに、送信時のメッセージ エンティティのスナップショットが必要です。ただし、単純に連絡先エンティティを削除すると、スナップショットの整合性が失われます。そうでない場合は、無効なキーが残ります。

コントローラーのロジックまたはモデルの変更において、この状況をどのように処理しますか? 


    class User(db.Model):
        email = db.EmailProperty(required=True)

    class Contact(db.Model): 
        email = db.EmailProperty(required=True) 
        user = db.ReferenceProperty(User, collection_name='contacts') 

    class Message(db.Model): 
        recipients = db.ListProperty(db.Key)   # contacts 
        sender = db.ReferenceProperty(User, collection_name='messages') 
        body = db.TextProperty() 
        is_emailed = db.BooleanProperty(default=False)
4

2 に答える 2

2

連絡先モデルに「削除済み」(または削除の日時などのより適切なもの) のブール フィールドを追加して、連絡先が物理的に削除されることはなく、そのフィールドが設定されたときに「論理的に」のみ削除されるようにします。（これにより、必要に応じて、「削除された古い連絡先を表示する」、「削除を取り消す」機能など、他のクールな機能を提供することもできます）.

これは、履歴の整合性 (および/または「監査可能性」などの同様の要件) を維持するために必要なすべてのストレージ システムで共通のアプローチです。

論理的に削除された膨大な量のエンティティがシステム パフォーマンスに損害を与える恐れがある場合、古典的な代替手段は、別の同一のモデル「DeletedContacts」を使用することですが、外部キーの制約により、より多くの作業が必要になりますrecipients。外部キーの整合性が必要な場合deleted_recipientsは、フィールドを使用します (ただし、キーだけを使用する場合は、この追加作業は必要ありません)。

平均的なユーザーが、前の段落で説明した最適化を保証するほど膨大な割合の連絡先を削除するとは思えないので、この場合は単純な「削除済み」フィールドを使用します。

于 2010-06-11T04:52:10.970 に答える
0

または、電子メール アドレスをキー名に移動し、ユーザーを親エンティティとして設定することで、Contact モデルをリファクタリングすることもできます。受信者プロパティは、生の電子メール アドレスの文字列リストに変更されます。これにより、メール受信者の静的なリストが得られます。それぞれに対応する一連のエンティティをフェッチしたり、そのようなエンティティがまだ存在している必要はありません。連絡先エンティティをフェッチする場合は、ユーザーと受信者アドレスからキーを簡単に作成できます。

ここでの制限の 1 つは、既存の連絡先エンティティの電子メール アドレスを変更できないことですが、とにかくその問題があると思います。既存のモデルで連絡先アドレスを変更すると、送信されたメッセージの受信者がさかのぼって変更されますが、これは問題であることがわかっています。

于 2010-06-11T14:37:25.967 に答える