docs: for sql db migration to 1.1 recommend --fake-initial

[ploxiln]

... and --run-syncdb should no longer be needed.

Initial migrations were created for all models just before 1.1.0
in d1912d4. Prior to that, some models did not have any
migrations (and no initial migration), so --run-syncdb was needed
to create tables for them. But now that they have initial migrations,
those migrations run because django knows they have never been
applied, and they fail because the tables already exist. The
--fake-initial option is designed for this situation: it considers
initial migrations already applied if the tables already exist.

fixes #2412
replaces #2126

conflicts with #2409 and this is a tiny change so I'd be fine with rebasing this after that lands

[deniszh]

@ploxiln : will it work for all Django versions? Even if we upgrading from Graphite 0.9.x and/or Django 1.4 ?
Because --run-syncdb was added because normal migrate command did nothing before...

[ploxiln]

--run-syncdb was needed before graphite-web 1.1, but with 1.1+ it should not be needed, even for databases originally created with graphite-web 0.9.x and older django. While figuring out #2412 also I tested making a new database from nothing, without --run-syncdb, and all tables were created (by initial migrations which are now present).

(Now --fake-initial may be needed only because --run-syncdb was used before, when it was needed.)

[deniszh]

@ploxiln : maybe that should be mentioned in docs too? Could you please amend it? Thanks!

[ploxiln]

possibly worth mentioning: --fake-initial was added in django 1.8 and --run-syncdb was added in django 1.9
(according to https://docs.djangoproject.com/en/1.9/ref/django-admin/#migrate)

[ploxiln]

looks like, in django 1.8 and earlier, the behavior of --run-syncdb was unconditionally provided:

No arguments: All migrated apps have all of their migrations run, and all unmigrated apps are synchronized with the database

[ploxiln]

OK, I'll try adding a bit more to the docs about this

[piotr1212]

I'm wondering all the time if we could automate this stuff on app startup? Just like Grafana does.

[ploxiln]

Let me know how that looks/sounds.

I'll squash commits before merge.

[deniszh]

For me, it looks great. Maybe I could ask @gwaldo to check?

[ploxiln]

Good idea - I think I figured this out, but I'm no django expert :)

[DanCech]

Is there any harm in always recommending users specify --fake-initial, ie having it in the example command?

[ploxiln]

I don't think there would be any harm in always using --fake-initial.

It should be needed at most once, when migrating from < 1.1 to >= 1.1, and the two places that that I did not include --fake-initial in the example were about "setting up a new database" - so I guess I did not want to encourage "just type this even though it does not make sense".

[deniszh]

OK, I'm merging this for now.