Migrations During Development

[Timothy W. Cook]

Django 1.8  Python 3.4 PostgreSQL 9.3

During development I am creating several migrations. It seems unnecessary to keep these since they only exist on my dev machine.  

Any data that I have created can be thrown away too.

Is it safe to delete these migrations  (and the database) before deploying to the next stage for testing by users? 

--

============================================
Timothy Cook
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook

MLHIM http://www.mlhim.org

[Filipe Ximenes]

You should keep all project migrations, they will be used to update the database everytime a change is made. This applies to your local project, the staging server (if you have one) and your production server.

If you are worried about having to many migrations, you can delete the ones that were not applied in other machines, and generate a single one with all the changes.

About the database, it can be deleted, but you don't need to do this, your database data should only exist in your computer and not in the Django project you are deploying.

--
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...@googlegroups.com.
To post to this group, send email to django...@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/CA%2B%3DOU3WNb8XWUWLyN%2B7fq4u7Er3dczOqgBKLODdVnE3cLxOr-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Filipe Ximenes +55 (81) 8245-9204 Vinta Software Studio http://www.vinta.com.br

[Jorge Andrés Vergara Ebratt]

Are you using version control like GIT? I save the migration folder with the __init__.py in GIT, nothing else, because al the migrations will be diferent in the diferent servers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAA-QWB2RW_39b-8nm0Jm%2BAg9%2Bc%3DV0F4%3Dnm%3D%2B3DM7U-f3njV%3DNw%40mail.gmail.com.

[Mike Dewhirst]

On 25/04/2015 10:26 PM, Timothy W. Cook wrote:
> Django 1.8 Â Python 3.4 PostgreSQL 9.3

>
> During development I am creating several migrations. It seems

> unnecessary to keep these since they only exist on my dev machine. Â

> Any data that I have created can be thrown away too.
>

> Is it safe to delete these migrations  (and the database) before
> deploying to the next stage for testing by users?Â

If the data can be thrown away I would have no hesitation in dropping
the entire database, deleting migrations and starting again.

There will come a point when you need to create a database for the users
to enter their data. From that moment, your dev database and the
production database must be kept in sync. That is when migrations must
change your dev database and be stored in your repo to be applied
against the production database each time you deploy updates to production.

I'm still learning about migrations but I can't see anything wrong with
answering yes to your question.

mike

>
>
> --
>
> ============================================
> Timothy Cook
> LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook

> MLHIMÂ http://www.mlhim.org <http://www.mlhim.org/>

>
> --
> 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...@googlegroups.com

> <mailto:django-users...@googlegroups.com>.

> To post to this group, send email to django...@googlegroups.com

> <mailto:django...@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/CA%2B%3DOU3WNb8XWUWLyN%2B7fq4u7Er3dczOqgBKLODdVnE3cLxOr-g%40mail.gmail.com

> <https://groups.google.com/d/msgid/django-users/CA%2B%3DOU3WNb8XWUWLyN%2B7fq4u7Er3dczOqgBKLODdVnE3cLxOr-g%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Timothy W. Cook]

On Sat, Apr 25, 2015 at 9:48 AM, Jorge Andrés Vergara Ebratt <jave...@gmail.com> wrote:

Are you using version control like GIT? I save the migration folder with the __init__.py in GIT, nothing else, because al the migrations will be diferent in the diferent servers.

​This is probably what I should have done. I have been saving them all to the git repo.  

I will likely delete them from git before I start deploying to other machines and setup git to not track anything except the __init__.py 

​

 

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAAeX05H23hsbciqm%3DXn-PgcGpsA-ezL2Pnx4joP6rWJ%2Bkeirgw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

[Javier Guerra Giraldez]

On Sat, Apr 25, 2015 at 12:08 PM, Timothy W. Cook <t...@mlhim.org> wrote:
>
> On Sat, Apr 25, 2015 at 9:48 AM, Jorge Andrés Vergara Ebratt <jave...@gmail.com> wrote:
>>
>> Are you using version control like GIT? I save the migration folder with the __init__.py in GIT, nothing else, because al the migrations will be diferent in the diferent servers.
>>
>
> This is probably what I should have done. I have been saving them all to the git repo.

with South i used to save them to the repo too and push whole to
production. haven't tried Django migrations yet; is there any
difference that make this more appropriate?

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?

--
Javier

[Timothy W. Cook]

On Sat, Apr 25, 2015 at 2:15 PM, Javier Guerra Giraldez <jav...@guerrag.com> wrote:

 

with South i used to save them to the repo too and push whole to
production.  haven't tried Django migrations yet; is there any
difference that make this more appropriate?

​Hmmm, good question. That was kind of my question. With South I always saved them.  This is my first project with using Django migrations.  There doesn't seem to be much difference. ​

 

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. 

​

 

[Javier Guerra Giraldez]

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

[Abhaya Agarwal]

Hi Timothy,

Assuming as an example that 0002_<>.py is the migration that you have already applied to production server, this is the scheme I follow:

• Make sure you have your local db up to date i.e. all the model changes have been applied to database.
• Fake a reversal to the last migration already applied to prod. In this case: manage.py migrate --fake <app_name> 0002
• delete all the migration files after 0002
• run makemigrations: manage.py makemigrations 
• Fake application of the new single migration: manage.py migrate --fake <app>

Now you have a single migration representing all the db changes since the last deploy. Hope this helps.

Regards,

Abhaya

--
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...@googlegroups.com.
To post to this group, send email to django...@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/CA%2B%3DOU3WNb8XWUWLyN%2B7fq4u7Er3dczOqgBKLODdVnE3cLxOr-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

-------------------------------------------------
blog: http://abhaga.blogspot.com
Twitter: http://twitter.com/abhaga
-------------------------------------------------

[Carl Meyer]

On 04/25/2015 06:48 AM, Jorge Andrés Vergara Ebratt wrote:
> Are you using version control like GIT? I save the migration folder with
> the __init__.py in GIT, nothing else, because al the migrations will be
> diferent in the diferent servers.

This is not a good idea. Migrations should be committed to git, and
should be the same on all deployments. Otherwise they do not serve their
purpose of ensuring that all deployments end up with the same database
schema.

Carl

[Carl Meyer]

Migrations should be committed to VCS in both South and in Django
migrations.

Carl

[Carl Meyer]

On 04/25/2015 11:28 AM, Timothy W. Cook 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.

If you only have one deployment (your local machine), you can erase all
your migrations and "start over" anytime with a new initial migration,
with no problems.

Once you have additional deployments (either other developers' machines,
or staging or production deployments), you shouldn't remove or change
any migrations that have been pushed to those other deployments.

You can use the "squash" feature [1] to squash a set of historical
migrations down to a single migration. This requires a phased
deployment, where you first push out a version including both the new
squashed migration and all the old replaced migrations, and then later
(once you are confident all deployments are up to date) you can safely
remove the old replaced migrations.

It's also true that if you have a series of new migrations locally that
haven't yet been pushed to any other deployment, you can delete and
replace them with a single migration before pushing.

It's very much like VCS commits: it's ok to edit your local history, but
you have to be a lot more careful with history that you've already
shared with others.

Carl

[Carl Meyer]

On 04/25/2015 05:18 PM, Carl Meyer wrote:
> You can use the "squash" feature [1] to squash a set of historical
> migrations down to a single migration.

Forgot this link:
https://docs.djangoproject.com/en/1.8/topics/migrations/#squashing-migrations

Carl

[marcin....@gmail.com]

It depends about your workflow - if migrations were applied only on your machine, revert them and modify.

South migrations (and Django migrations, which were based on South) may be problematic in speific cases, i.e. during merging or when executed unintentionally from uncleaned *.pyc files, but you're safe until you commit (& spread) changes. And you shouldn't rely on automatic squashing ;)

BR

Marcin