Michal,
I had to read your response a few times but I finally got it. I was
reading
that all migrations are created in development only and then applied during
production.
So, during development you use makemigrations and then when deployed
you migrate.
Thus, if you add a new feature, you make the migration on the
development system then push it to producation, where you can
issue the command python manage.py migrate.
I just thought of something that is related to migrations. Suppose,
with my contacts app, I want to change the name field to be
first_name + last_name. If there is data in the database, how will
this be handled?
I'll give it a try and see what happens. It is just the development machine
that has the data.
Thanks,
Bruce
On Monday, May 2, 2016 at 11:48:52 AM UTC-4, Michal Petrucha wrote:
>
> On Mon, May 02, 2016 at 08:37:43AM -0700, Bruce Whealton wrote:
> > I'm not sure if it is ok to use python manage.py makemigrations on the
> > production server or if one should just do that locally and then import
> it.
>
> Hi Bruce,
>
> Migrations are a part of your application's code base, and they should
> be treated as such. In other words, you create all migrations during
> development, and make sure to include them in your code repository,
> and then as part of your deployment strategy, you only apply them in
> the production environment.
>
> Cheers,
>
> Michal
>
--
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/bd085f78-6126-4583-8570-1a3ee66778cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
