Opened 9 years ago
Closed 9 years ago
#26304 closed Bug (fixed)
Unable to use unmanaged ManyToMany through models when backed by a View.
Reported by: | Matthew Schinckel | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Given an unmanaged ManyToMany through model, (i.e., where Meta.managed is explicitly marked as False), running tests attempts to call "sqlflush", and truncate this table.
However, I have a situation where this model is actually being backed by a (Postgres) View, which cannot be truncated.
It seems that https://github.com/django/django/blob/53ccffdb8c8e47a4d4304df453d8c79a9be295ab/django/db/backends/base/introspection.py#L83 shows that all many-to-many fields are added for flushing, ignoring managed status.
I believe that this can be resolved by only adding those many-to-many fields that do not have a through model marked as unmanaged.
Change History (7)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
Has patch: | set |
---|---|
Patch needs improvement: | set |
Triage Stage: | Unreviewed → Accepted |
Version: | 1.9 → master |
follow-up: 4 comment:3 by , 9 years ago
I believe that this can be resolved by only adding those many-to-many fields that do not have a through model marked as unmanaged.
Don't you run into an issue if the rows on either end of the M2M field are truncated but the rows in the through table still exist pointing to nowhere, which effectively would blow up with broken foreignkey constraints?
comment:4 by , 9 years ago
Replying to MarkusH:
I believe that this can be resolved by only adding those many-to-many fields that do not have a through model marked as unmanaged.
Don't you run into an issue if the rows on either end of the M2M field are truncated but the rows in the through table still exist pointing to nowhere, which effectively would blow up with broken foreignkey constraints?
In my case, it is a View that is acting as the model source: which cannot _ever_ be truncated. In this particular instance, it's something very much like http://schinckel.net/2016/01/27/django-trees-via-closure-view/
comment:5 by , 9 years ago
Patch needs improvement: | unset |
---|
comment:6 by , 9 years ago
Yes, in your case. I'm thinking more about the general case if we "just don't add the m2m fields". I think we should check if the through field "is a table" / "is not a view".
Oh, in case it's not clear, this is an unmanaged through model between two managed models.
Otherwise https://github.com/django/django/blob/53ccffdb8c8e47a4d4304df453d8c79a9be295ab/tests/unmanaged_models/models.py#L99-L105 would show a failure...