Question

I am designing an application where users send/receive records and I would like deletes to be separated for each user listed in the record (one user's delete will not hide the record from the other user).

My base model design looks like this:

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()

Would it be an improvement to replace the archived_by_xxxx fields with a ManyToManyField to accounts.CommonUserProfile that is responsible for storing a list of users who have hidden (soft-deleted) the record? It seems that would make client-side code simpler down the line. How is soft-delete typically implemented on a per-user basis?

Was it helpful?

Solution

I don't think there is a general industry-standard solution for this. Just do whatever you feel will get the job done for you specific application.

From what I understood, your message can only be viewed by a sender as well as a recipient, in which case I see no reason to add a M2M field. It will only slow down your application as it will use extra resources to do the extra lookups. However if you will need to extend you application where many users will be able to see a single message (e.g. group conversation), then it would make sense to add M2M field.

Bottom line is do whatever fits you application needs. Like always, its a compromise between abstraction (more flexibility) to performance.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top