Changing many-to-many field creates additional HistoricalRecord

[VeraBoersma]

Changing many-to-many field creates additional HistoricalRecord

[VeraBoersma]

To clarify, we intend to use django-simple-history in a database which has a user interface, using the generic create and update views from Django, which I think causes the issue, as that one might have the different .add() and .save() actions in there causing the duplicate records.

We have now locally managed to fix it by removing duplicate history records (based on user and timestamp (to the second) before parsing them.

In case anyone is interested:

    def remove_duplicate_records(self, object_history: HistoricalRecords) -> List[HistoricalChanges]:
        """
        Removes duplicate history records based on user and timestamp.
        This is to accommodate for that when changing m2m fields, django-simple-history creates 2 historical records.
        One when the .add() is called one when .save() is called in Django's generic create and update views.
        Only the first in the list of each set of duplicated entries needs to be kept, as that holds all the changes.
        :param object_history: HistoricalRecords: List of historical records for an object containing potential
                               duplicates
        :return: List[HistoricalChanges]: Deduplicated list of historical records for the object.
        """
        deduplicated_records = [object_history[0]]  # initiate with the latest change as first entry
        for i in range(len(object_history) - 1):
            previous_record = object_history[i]
            current_record = object_history[i + 1]
            previous_timestamp = previous_record.history_date.strftime('%Y-%m-%d %H:%M:%S')
            current_timestamp = current_record.history_date.strftime('%Y-%m-%d %H:%M:%S')
            # When the current record differs from the previous one on user and timestamp, add it to deduplicated
            if current_record.history_user != previous_record.history_user or current_timestamp != previous_timestamp:
                deduplicated_records.append(current_record)
        return deduplicated_records

[ddabble]

I don't think it's a viable option fixing this (intended) behavior, unfortunately. This is because updating M2M fields necessarily changes a different table than the model's table - which happens in a separate transaction from updating the model's table (unless it's part of an atomic transaction, of course) - and since this library does not keep track of transactions, we have to create two historical records in these cases.

Update but do not save the m2m field of the instance holding the m2m field

I'm assuming you're talking about calling the add(), remove() or set() M2M manager methods..? Because calling them will immediately change the M2M table, regardless of whether e.g. save() has been called on the model object, in case you weren't already aware 🙂

[ddabble]

Other than that, thank you for posting the code that solved your problem!

Please reopen if you'd like to discuss alternative solutions 🙂