Механизм приложения: как был бы Вы … объекты создания снимков

Скажем, у Вас есть два вида, сообщение и Контакт, связанный дб. 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)

1
задан Andrew B. 11 June 2010 в 03:55
поделиться

2 ответа

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

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

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

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

2
ответ дан 2 September 2019 в 23:49
поделиться

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

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

0
ответ дан 2 September 2019 в 23:49
поделиться
Другие вопросы по тегам:

Похожие вопросы: