Дизайн на модел с меко изтриване на потребител в Django

Проектирам приложение, в което потребителите изпращат/получават записи и бих искал изтриванията да бъдат разделени за всеки потребител, посочен в записа (изтриването на един потребител няма да скрие записа от другия потребител).

Моят дизайн на базовия модел изглежда така:

class BasePrivateMessage(TimeStampedModel):
    accepted = models.NullBooleanField(default=None, null=True, blank=True)
    # fields in question 
    archived_by_recipient = models.BooleanField(default=False)
    archived_by_sender = models.BooleanField(default=False)

    read = models.BooleanField(default=False,
                               help_text='Recipient has viewed.')
    recipient = models.ForeignKey('accounts.CommonUserProfile',
                              related_name='%(class)s_received')

    sender = models.ForeignKey('accounts.CommonUserProfile',
                               related_name='%(class)s_sent')
    message_body = models.TextField()

Би ли било подобрение да се заменят полетата archived_by_xxxx с ManyToManyField до accounts.CommonUserProfile, които са отговорни за съхраняването на списък с потребители, които са скрили (меко изтрили) записа? Изглежда, че това би направило клиентския код по-опростен. Как обикновено се прилага мекото изтриване за всеки потребител?


person kevins    schedule 10.12.2013    source източник


Отговори (1)


Не мисля, че има общо стандартно за индустрията решение за това. Просто направете всичко, което смятате, че ще свърши работата за вашето конкретно приложение.

Доколкото разбрах, вашето съобщение може да се види само от подател, както и от получател, в който случай не виждам причина да добавяте поле M2M. Това само ще забави вашето приложение, тъй като ще използва допълнителни ресурси за извършване на допълнителни търсения. Ако обаче трябва да разширите приложението си, където много потребители ще могат да виждат едно съобщение (напр. групов разговор), тогава би имало смисъл да добавите поле M2M.

В крайна сметка правете всичко, което отговаря на вашите нужди на приложението. Както винаги, това е компромис между абстракция (повече гъвкавост) и изпълнение.

person miki725    schedule 11.12.2013
comment
Благодаря ти; това изглежда като добър съвет. Може да е трудно да се намерят най-добри практики за неща като това и често нямам представа дали съм тръгнал в грешна посока с дизайна на модели. Оценявам го! - person kevins; 11.12.2013