squash migrations 0001-0006

[n2ygk]

@jleclanche I needed to do this anyway for overriding migrations due to django-pyodbc-azure/SQL Server deficiencies (#663, #583) so thought I might as well submit it. Merge or Close at your pleasure.

[coveralls]

Pull Request Test Coverage Report for Build 1059

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 92.88%

---

Totals
Change from base Build 1058:	0.0%
Covered Lines:	1161
Relevant Lines:	1250

---

💛 - Coveralls

[n2ygk]

FWIW michiya/django-pyodbc-azure#189 fixes the django-pyodbc-azure limitation that lead to this need to squash.

[jnm]

@n2ygk, @auvipy, thank you for your work on this project. I do want to mention, for future reference and in light of issues like #809, that this method of squashing migrations does not follow the long-standing instructions in the Django documentation:

You should commit this migration but leave the old ones in place; the new migration will be used for new installs. Once you are sure all instances of the codebase have applied the migrations you squashed, you can delete them.

I'd humbly request that if future squashes are needed:

1. The creation of the new, squashed migration and the deletion of the old migrations do not happen in the same release;
2. The squashed migration name indicates that it is a squash (as shown in the Django documentation's example, 0001_squashed_0004_undo_somthing.py) instead of reusing an existing migration name, which will already be logged as complete in existing installations' django_migrations table. That should make any problems due to missed intermediate migration steps or overlooked release notes more obvious.

Thanks for your consideration and thanks again for your work on this project.