boardinghouse.migrations.0005_group_views module

boardinghouse.migrations.0005_group_views.move_existing_to_schemata(apps, schema_editor)[source]

This is not really working that well at the moment. Perhaps we should look at using the migration operations that actually add/remove these tables?

Or maybe just give instructions about what to do if this case is detected?

boardinghouse.migrations.0005_group_views.private_auth_models(apps)[source]

Which of the django.contrib.auth models should be private, and more specifically, should also have an (empty) VIEW inside settings.PUBLIC_SCHEMA, so we don’t get exceptions when no schema is activated.

Note this takes into account the settings.PRIVATE_MODELS, to allow us to use the one migration for when boardinghouse.contrib.groups is installed (or auth.group is added by other means).

boardinghouse.migrations.0005_group_views.view_from_model(model)[source]

Return a DDL statement that creates a VIEW based on the model.

The view MUST always return an empty query, and writes to the view should be silently discarded without error.