Closed brutasse closed 11 years ago
BTW, comparedb is currently broken because of this, it runs the migrations on the _compare
database instead of forcing Django's syncdb.
I have to agree with brutasse: hacking syncdb doesn't seem like a good idea at all - it might be seen as "nashvegas breaks django"
I think #52 provides a good compromise to this issue. syncdb by default will running migration, but provides a --skip-migrations flag if you want Django's version. I hope this is sufficient for anyone that needs to run syncdb manually or via a script that they will now have this --skip-migrations flag to get the behavior they desire.
Since bf38d077257bd9354c7bbf786288c2697fb0c534, calling
syncdb
with nashvegas installed callsupgradedb
. When creating a new DB from a project that has a lot of migrations, the python migrations which use the project's models are not necessarily in sync with the DB at the time of the migration (for instance, different field names between the DB and the python models), and the project may be in a stage where the database can't even be sync'd.The larger issue is forward-compatibility of migrations but this is not always possible. Anyway, the migration process should be:
upgradedb -x
syncdb
and seed the migrations since there is no need to go through the whole migration process on an empty DBNashvegas used to warn the user when trying to run
syncdb
with nashvegas installed, and the usual workflow was to run upgradedb + syncdb on all deploys. This could work very well here, andupgradedb
could do the following:Check if the DB is being synced for the 1st time. If so: do syncdb + seed migrations Else:
upgradedb -x
&&syncdb
This way the user only uses
upgradedb
, gets a big fat warning when trying to usesyncdb
directly andupgradedb
callssyncdb
at the appropriate time.Thoughts?
46 implements the upgrade case but not the 1st sync case.