App Engine: как бы вы ... снимки объектов

Question

Допустим, у вас есть два вида, сообщение и контакт, связанные db.ListProperty ключей на Сообщение. Пользователь создает сообщение, добавляет некоторые контакты в качестве получателей и по электронной почте сообщение. Позже пользователь удаляет один из контактных лиц, который был получателем сообщение. Наше приложение должно удалить соответствующий контакт объекта, но мы хотим сохранить исходный список получателей для сообщение, которое было отправлено для записей пользователя. По сути, мы хотим снимок объекта сообщения во время его отправки. Если мы наивно удалить контактную сущность, однако мы теряем целостность снимка; если не, мы остались с неверным ключом.

Как бы вы справились с этой ситуацией, либо в логике контроллера, либо в изменении модели?

    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)

Answer 1

Я бы добавил логическое поле «удалено» (или что-то еще более необычное, например, дату и время удаления) в модель контактов, чтобы контакты никогда не удалялись физически, а только «логически» удалялись, когда это полеустановлено.(Это также позволяет вам предлагать другие интересные функции, такие как «показывать мои старые удаленные контакты», «восстановить» и т. Д., Если хотите).

Это общий подход во всех системах хранения, которыетребуется поддерживать историческую целостность (и / или аналогичные требования, такие как «проверяемость»).

В тех случаях, когда огромное количество логически удаленных объектов угрожает производительности системы, классическая альтернатива состоит в том, чтобы иметь отдельный,идентичная модель "DeletedContacts", но ограничения внешнего ключа требуют больше работы, например, класс Message должен иметь и recipients, и deleted_recipients поля , если вам нужна целостность внешнего ключа (но с использованием только ключей, каквы делаете, эта дополнительная работа не понадобится).

Я сомневаюсь, что средний пользователь удалит такой огромный процент своих контактов, чтобы гарантировать оптимизацию, описанную в предыдущем абзаце, поэтому в этом случае ябы перейти с простым «удаленным» полем.

Answer 2

В качестве альтернативы, вы можете провести рефакторинг своей модели контактов, переместив адрес электронной почты в имя ключа и установив пользователя в качестве родительского объекта. Свойство получателей изменится на список строк необработанных адресов электронной почты. Это дает вам статический список получателей электронной почты без необходимости извлекать набор соответствующих сущностей для каждого или требовать, чтобы такие сущности все еще существовали. Если вы хотите получить контактные объекты, вы можете легко создать их ключи из адреса пользователя и получателя.

Одним из ограничений здесь является то, что адрес электронной почты существующей контактной сущности не может быть изменен, но я думаю, что у вас все равно есть эта проблема. Изменение адреса контакта с вашей существующей моделью может задним числом изменить получателей отправленного сообщения, что, как мы знаем, является проблемой.