A simple app providing three models: Country, Region and City model. Also provided, a command to insert or update data from geonames database dumps. Status: stable.
I understand that it may be a design choice to delegate makemigrations and migrate to the client. It makes sense when django is capable of handling those changes alone. Several other times, however, migrations have to be written manually in order to be backwards compatible and whatknot.
In that vein, our project ensures that those migrations are not missing in our CI process, blocking pull requests that make database without syncing the migrations.
Due to that, we had to disable those checks when incorporating django-cities-light. Thanks for the work btw, it is a lot better than the solution we used previously.
Therefore i suggest that it may be considered, for compatibility with good industry practices, to ship migrations in the relevant {app_name}/fixtures folders.
Since this is a design decision, i chose to open an issue for discussion rather than issuing a new pull request.
Hello guys.
I understand that it may be a design choice to delegate
makemigrations
andmigrate
to the client. It makes sense when django is capable of handling those changes alone. Several other times, however, migrations have to be written manually in order to be backwards compatible and whatknot.In that vein, our project ensures that those migrations are not missing in our CI process, blocking pull requests that make database without syncing the migrations.
Due to that, we had to disable those checks when incorporating django-cities-light. Thanks for the work btw, it is a lot better than the solution we used previously.
Therefore i suggest that it may be considered, for compatibility with good industry practices, to ship migrations in the relevant
{app_name}/fixtures
folders.Since this is a design decision, i chose to open an issue for discussion rather than issuing a new pull request.
Thanks for your time, John.