On Sat, Apr 25, 2015 at 12:28 PM, Timothy W. Cook <t...@mlhim.org> wrote: > On Sat, Apr 25, 2015 at 2:15 PM, Javier Guerra Giraldez <jav...@guerrag.com> > wrote: >> if you don't store migrations, then you have to generate them on each >> production update, right? if so, wouldn't they count as untested >> code? how about manually tweaked, or data migrations? > > That will certainly be true once you start using a staging or production > server. > But before they they are just a kind left over creative ideas. :-) Not > really useful for anything in the future, AFAICS.
South used to have a feature to "flatten" migrations (i never tried it, so don't know exactly how that worked). maybe a middle point between "don't save, generate at each server" and "save everything, get the same whole story everywhere" would be to do this before commit (or before merging to trunk): - revert migration directories to the currently deployed point. - revert development database to the same point (maybe pulling the current schema from production/staging) - make (and test) a single migration - commit everything. -- Javier -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFkDaoRupubbCuQZo2qpJpX254c3-EBxo1_uysd1Pz08Q_Yd6A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
