Installed database extensions are not kept in the squashed migrations about django-squash HOT 6 CLOSED

Hi Felix:

We've stopped using non-elidable migrations. There's no reason to use them when you can perform the same logic using post_migration signals (from django.db.models.signals import post_migrate). We moved all logic that we were trying to keep in non-elidable migration operations into functions that run after migrations.

--Phil.

from django-squash.

Hi @philfriesen , by reading your docs, you inspired me to actually do the same for almost all of my non-elidable migrations and I'm super happy with the result! It is more maintainable and reliable like that. Thanks a lot for the pattern!

I don't understand however how you can put BtreeGistExtension() somewhere else than in a migration, do you have a technique to do that?

Thanks!

from django-squash.

What do your models look like?

from django-squash.

We put it in our DB creation scripts:

`
DROP DATABASE IF EXISTS your_db_name;

CREATE DATABASE your_db_name WITH ENCODING 'UTF8' LC_CTYPE 'en_US.UTF-8' LC_COLLATE 'en_US.UTF-8' TEMPLATE TEMPLATE0;
GRANT ALL PRIVILEGES ON DATABASE your_db_name TO your_db_role_aka_user;
\connect your_db_name;
create extension if not exists hstore schema pg_catalog;
`

from django-squash.

From what I can see (very shallow reading) about using HStoreField, ExclusionConstraint, etc., is you currently need to manually add your own BtreeGistExtension/BtreeGisExtension/etc after running makemigrations to the migration file that gets created. The idea of having you add these operations manually rubs me the wrong way, but unfortunately at the moment, if core django does not support it, I would have to follow their lead and say we won't either :/

django-squash at the most basic level is a wrapper around makemigrations that is "squash aware", "when" or "if" django decides to add this automatic functionality to makemigrations we will benefit automatically.

from django-squash.

@kingbuzzman great ok I understand, yes indeed it's up to me to add this extension or not.
I was just thinking that, since running manage.py squash_migrations does keep the RunPython migrations (and it's then up to me to delete them or not), then it would also be possible to keep the Postgres extensions migrations and leave it up to me to remove them or not.

No problem if it's not possible I will have to be very careful when running the command!

@philfriesen thanks, for now we would like to avoid having to write raw sql although we will certainly have to some day!

from django-squash.