On Wed, Sep 10, 2014 at 02:06:09PM -0500, Andrew Pinkham wrote:
> On Sep 10, 2014, at 12:25 PM, John Schmitt wrote:
> > Which file? What do I look for? What do I 'verify' and to what should it
> > be compared?
>
> When you run `makemigrations app_name`, the output will inform you of the
> cre
On Sep 10, 2014, at 12:25 PM, John Schmitt wrote:
> Which file? What do I look for? What do I 'verify' and to what should it be
> compared?
When you run `makemigrations app_name`, the output will inform you of the
creation of at least one migration file, typically in
project_name/app_name/mi
On Wed, Sep 10, 2014 at 12:08:35PM -0500, Andrew Pinkham wrote:
> Hi Jesse,
...
> Quick heads up: `syncdb` is deprecated in Django 1.7. If you're using Django
> 1.7, you should first call `makemigrations`, verify the contents of the file,
> and then call `migrate` to build/alter the database. How
Hi Jesse,
Yes, in certain cases, native Django migrations may run very slowly.
https://code.djangoproject.com/ticket/22608
My understanding is that this should not be a problem unless you have a huge
number of apps and models (note how the second benchmark from Paul in the
ticket has 200 models
Hi all,
First post here. I'm currently trying to transition to django migrations
which seems pretty bad ass. We currently do not use south, and keep track
of migrations manually (yuk). However, initializing a new database is
pretty straight forward; syncdb. It's quick, and efficient. Once we cr
5 matches
Mail list logo
