Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Track history of M2M fields [WIP] #370

Closed
wants to merge 1 commit into from
Closed

Conversation

avalanchy
Copy link

@avalanchy avalanchy commented Apr 12, 2018

Yet another attempt of introducing many to many fields support for django-simple-history.

Today I rebased this with master. Before that I was using this for like two months, but it was rebased with django-20 branch.

Not sure when I will continue working on this, but for now I decided to share the code with you to collect some feedback and know if this is at least good direction.

Current solution is backward compatible, it means that m2m fields aren't tracked by default. Programmer needs to define which m2m fields should be tracked and pass them within HistoricalRecords field declaration (see api 1),

Such field definition is detected by Django makemigration and it that will create new table Historical<M2mTroughModelName>.

Under the hood tracking version changes and creating historical entries is based on Django signals.

As this is WIP, the only working way of this feature is with the new decorator. This new decorator is a way to manipulate m2m relation and to track their history but without tracking history of original object (see api 2).

api 1. Defining which m2m fields should be tracked:

class Business(Model):
    attachments = models.ManyToManyField(Attachment)
    history = HistoricalRecords(m2m_fields=[attachments])

api 2. Saving with new decorator, that prevents from creating historical entry of base object:

self.save()
with self.use_last_historical_record():
    self.attachments.clear()

Looking forward to see some comments. Thanks!

@rossmechanic
Copy link
Collaborator

Thanks @avalanchy ! I actually like this approach but would prefer to have discussion around this in an issue rather than in an open PR and then move it to PR when we know exactly what we want. Opening #399 to discuss.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants