Unable to use unmanaged ManyToMany through models when backed by a View.

[Matthew Schinckel]

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.

[Matthew Schinckel]

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...

[Markus Holtermann]

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?

[Matthew Schinckel]

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/

That's not to say you are incorrect, I think there may still be situations such as you describe: I guess there could be cause to use an unmanaged through model with managed models at either end, that was actually a table.

[Markus Holtermann]

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".

[Tim Graham <timograham@…>]

In 60633ef:

Fixed #26304 -- Ignored unmanaged through model in table introspection.