{"action":"created","issue":{"url":"https://api.github.com/repos/jleclanche/django-push-notifications/issues/186","labels_url":"https://api.github.com/repos/jleclanche/django-push-notifications/issues/186/labels{/name}","comments_url":"https://api.github.com/repos/jleclanche/django-push-notifications/issues/186/comments","events_url":"https://api.github.com/repos/jleclanche/django-push-notifications/issues/186/events","html_url":"https://github.com/jleclanche/django-push-notifications/issues/186","id":94138440,"number":186,"title":"Initial migration file shouldn't have been updated. It's already been sync'd to production DBs.","user":{"login":"nceruchalu","id":1156336,"avatar_url":"https://avatars.githubusercontent.com/u/1156336?v=3","gravatar_id":"","url":"https://api.github.com/users/nceruchalu","html_url":"https://github.com/nceruchalu","followers_url":"https://api.github.com/users/nceruchalu/followers","following_url":"https://api.github.com/users/nceruchalu/following{/other_user}","gists_url":"https://api.github.com/users/nceruchalu/gists{/gist_id}","starred_url":"https://api.github.com/users/nceruchalu/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nceruchalu/subscriptions","organizations_url":"https://api.github.com/users/nceruchalu/orgs","repos_url":"https://api.github.com/users/nceruchalu/repos","events_url":"https://api.github.com/users/nceruchalu/events{/privacy}","received_events_url":"https://api.github.com/users/nceruchalu/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-07-09T19:53:01Z","updated_at":"2015-07-09T20:08:02Z","closed_at":null,"body":"A commit in v1.3.1, https://github.com/jleclanche/django-push-notifications/commit/8fcc265331605241a538ebc571dac912d08f2f9f, modified the original migration file `0001_initial.py`.  This works great for new users of this well-done project as they only have 1 migration file to read through.\r\n\r\nHowever this project has thankfully been around for some time and a number of us had already run a `manage.py migrate` which put this initial migration in our production DBs. **So any changes made to this migration file wouldn't have been picked up by django's migration tool.**\r\n\r\n**It would seem more appropriate to create a new migration file by running `manage.py makemigrations` and renaming it to something like `0002_add_db_index.py`**. This way our systems don't try to create new migration for those still on versions prior to v1.3.1. \r\nThose who already upgraded to v1.3.1 now have a migration file that isn't in sync with their DBs and have to manually add this index to fix that.\r\n\r\nThe suggested approach is in line with Django's notes on how the migrations tool works. It can be observed that too made many new migrations in the `auth app` in the upgrade from Django v1.7 to v1.8. This way nobody's database is out of sync with the migration files, and nobody's machine is auto-generating the necessary migration files.\r\n\r\nPlease let me know your thoughts on this. And thanks for the great work on this! Has definitely served multiple people in multiple projects! :smile: "},"comment":{"url":"https://api.github.com/repos/jleclanche/django-push-notifications/issues/comments/120130310","html_url":"https://github.com/jleclanche/django-push-notifications/issues/186#issuecomment-120130310","issue_url":"https://api.github.com/repos/jleclanche/django-push-notifications/issues/186","id":120130310,"user":{"login":"nceruchalu","id":1156336,"avatar_url":"https://avatars.githubusercontent.com/u/1156336?v=3","gravatar_id":"","url":"https://api.github.com/users/nceruchalu","html_url":"https://github.com/nceruchalu","followers_url":"https://api.github.com/users/nceruchalu/followers","following_url":"https://api.github.com/users/nceruchalu/following{/other_user}","gists_url":"https://api.github.com/users/nceruchalu/gists{/gist_id}","starred_url":"https://api.github.com/users/nceruchalu/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nceruchalu/subscriptions","organizations_url":"https://api.github.com/users/nceruchalu/orgs","repos_url":"https://api.github.com/users/nceruchalu/repos","events_url":"https://api.github.com/users/nceruchalu/events{/privacy}","received_events_url":"https://api.github.com/users/nceruchalu/received_events","type":"User","site_admin":false},"created_at":"2015-07-09T20:08:02Z","updated_at":"2015-07-09T20:08:02Z","body":"Thanks for the quick response!\r\n\r\nSo the thing about fake migrations is they just ensure the `django_migrations` table in the database have an entry that say a migration file has been applied. So in this case it will say the `0001_intial.py` migration file has been applied. However this is already the case as I've had this project running in production for a while.\r\n\r\nFrom the Django notes on fake migrations: **[\"Django won’t check that the table schema match your models, just that the right table names exist)\"](https://docs.djangoproject.com/en/1.8/topics/migrations/#upgrading-from-south)**\r\n\r\nSo yes you're right that I could go update my db manually and ensure that the table schema matches by adding this index to the `push_notifications_<device>` tables. A number of your pre-existing happy users might not be too keen on doing this though when you finally publish a new pip release."}}