Overriding AppConfig.get_model(s)

[Nick Sandford]

I was just working on #22986 and it seems that if the AppConfig.get_model(s) methods are overridden, migrations for models that are excluded are still run.

Is this a known issue? Am I abusing get_model(s) or should I file a ticket for this?

Cheers,
Nick

https://code.djangoproject.com/ticket/22986#comment:5

[Andrew Godwin]

Migrations instantiate their own copies of AppConfig and Apps and run from those, so you won't be able to affect them by overriding methods. If you want to exclude models from migrations use router.allow_migrate.

Andrew

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwcc5XrD8z7DheoUQE7A2yo6%2B052FkNhyzVv7Qsvk5z8JFZUQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Nick Sandford]

Ahh ok, that makes sense -- I guess there's no difference between overriding get_model(s) and manually deleting the model out of the source to the migrations.

I can't think of any decent way to use router.allow_migrate in sessions other than monkey patching it to do what I want. Any suggestions?

Would it be possible to detect that the models are being manually excluded rather than removed from the source and migrate them differently?

Cheers,
Nick

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFwN1upTQN2ATv4btfrnSCybBZ4CHR7pGXV%3Dc%3Dbe6nm7Wh9JKw%40mail.gmail.com.

[Andrew Godwin]

I don't think there's a way you can do this with migrations. You're not supposed to be able to change them at runtime based on settings; that was the cause of most of our bugs with swappable models.

Andrew

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwcc5WrEHhwA-U3h8R4qUa8mBvUd%2BXz%2BgSjwb0H8Yz6LAaVsA%40mail.gmail.com.

[Nick Sandford]

Isn't that essentially what's happening by respecting router.allow_migrate? Determining at runtime via a setting (DATABASE_ROUTERS) whether to apply migrations. From the perspective of a user, providing a custom database router makes sense for applications they don't control, but from the perspective of an reusable app developer who doesn't have access to the project's settings, using database routers seems a bit more cumbersome.

I guess I'm just thinking that having an alternative method would be useful. I'm happy to help find a solution if you feel it's a worthwhile pursuit.

Cheers,

Nick

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFwN1uqCaeGrc9K58ErPLP-m9UoztBXCVgNC4-9Nu4RJVKWUMQ%40mail.gmail.com.

[Andrew Godwin]

Yeah, but if you change the value of the routers during a project's lifetime it's up to you to fix the resulting issues (same as if you switch AUTH_USER_MODEL - you _cannot_ change this after project start without serious pain).

If you're happy saying the same thing about sessions, then go and tie the model's managed option to the setting - that should do what you want - but people are going to get real confused when they change the setting and the table isn't made for them.

Andrew

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwcc5VNhaGTEiogjvLOg30G4KMu1dLm1zA-bf%2BMW25%2BfMW1%2BA%40mail.gmail.com.

[Nick Sandford]

Managed might be the ticket then. I don't think it's too surprising to the user who configures a cache or file session backend that no database table is created. I think that's slightly less surprising than the status quo -- they configured a file session backend and when they run migrate they notice that a database table for sessions has been created, which might lead them to question if the session backend is working as intended. I'll pursue the meta option for now :).

If they start with the database backend, and switch at a later date to a non-database backend, then I'm comfortable to make it the user's responsibility to clean up the leftover database table, but were you suggesting if they start with a non-database backend and at some later stage decide to switch to a database backend it won't work?

Thanks for the help.

Nick

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFwN1uokHSqc8pMZ3fxnW1Ni1rFA2jYOz6zv%3DiAJW%3DFLMNAFEw%40mail.gmail.com.

[Andrew Godwin]

Actually, managed won't work, because that just affects if stuff gets put into migration files, IIRC - even if you change it it won't affect migrations.

The main problem is that whatever you do, Django is going to mark the migration as applied if you have sessions set to a non-db store and then when you switch the setting to a db store it's not going to magically mark the migration as unapplied and make the table again. People are going to have to run "./manage.py migrate --fake sessions zero; ./manage.py migrate sessions" to make the table.

The only sensible approach would be to change the session app's MIGRATION_MODULES based on the setting, to point to an empty set of migrations if it's non-db and a set with one to make the table with it in if it's db. This will have the intended effect but Django might get annoyed if you switch from db to non-db and now it has a migration applied that no longer exists on disk.

Andrew

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwcc5Uj63jwzr16L04sZHb5_jcTcjrcQh99F%3DT2xTzk5E5Myw%40mail.gmail.com.