I&#39;ve made a migration that added a new table and want to revert it and delete the migration, without creating a new migration.

How do I do it? Is there a command to revert last migration and then I can simply delete the migration file?


How to revert the last migration?

I was trying to create migrations within an existing app using the makemigrations command but it outputs &quot;No changes detected&quot;.

Usually I create new apps using the `startapp` command but did not use it for this app when I created it.

After debugging, I found that it is not creating migration because the `migrations` package/folder is missing from an app. 

Would it be better if it creates the folder if it is not there or am I missing something?

Django - makemigrations - No changes detected

I&#39;m planning to rename several models in an existing Django project where there are many other models that have foreign key relationships to the models I would like to rename. I&#39;m fairly certain this will require multiple migrations, but I&#39;m not sure of the exact procedure.

Let&#39;s say I start out with the following models within a Django app called `myapp`:

    class Foo(models.Model):
        name = models.CharField(unique=True, max_length=32)
        description = models.TextField(null=True, blank=True)
    
    
    class AnotherModel(models.Model):
        foo = models.ForeignKey(Foo)
        is_awesome = models.BooleanField()


    class YetAnotherModel(models.Model):
        foo = models.ForeignKey(Foo)
        is_ridonkulous = models.BooleanField()

I want to rename the `Foo` model because the name doesn&#39;t really make sense and is causing confusion in the code, and `Bar` would make for a much clearer name. 

From what I have read in the Django development documentation, I&#39;m assuming the following migration strategy:

Step 1
====

Modify `models.py`:

    class Bar(models.Model):  # &lt;-- changed model name
        name = models.CharField(unique=True, max_length=32)
        description = models.TextField(null=True, blank=True)
    
    
    class AnotherModel(models.Model):
        foo = models.ForeignKey(Bar)  # &lt;-- changed relation, but not field name
        is_awesome = models.BooleanField()


    class YetAnotherModel(models.Model):
        foo = models.ForeignKey(Bar)  # &lt;-- changed relation, but not field name
        is_ridonkulous = models.BooleanField()

Note the `AnotherModel` field name for `foo` doesn&#39;t change, but the relation is updated to the `Bar` model. My reasoning is that I shouldn&#39;t change too much at once and that if I changed this field name to `bar` I would risk losing the data in that column.

Step 2
====

Create an empty migration:

    python manage.py makemigrations --empty myapp

Step 3
====

Edit the `Migration` class in the migration file created in step 2 to add the `RenameModel` operation to the operations list:

    class Migration(migrations.Migration):
    
        dependencies = [
            (&#39;myapp&#39;, &#39;0001_initial&#39;),
        ]
    
        operations = [
            migrations.RenameModel(&#39;Foo&#39;, &#39;Bar&#39;)
        ]


Step 4
====

Apply the migration:

    python manage.py migrate

Step 5
====

Edit the related field names in `models.py`:

    class Bar(models.Model):
        name = models.CharField(unique=True, max_length=32)
        description = models.TextField(null=True, blank=True)
    
    
    class AnotherModel(models.Model):
        bar = models.ForeignKey(Bar)  # &lt;-- changed field name
        is_awesome = models.BooleanField()


    class YetAnotherModel(models.Model):
        bar = models.ForeignKey(Bar)  # &lt;-- changed field name
        is_ridonkulous = models.BooleanField()

Step 6
====

Create another empty migration:

    python manage.py makemigrations --empty myapp

Step 7
====

Edit the `Migration` class in the migration file created in step 6 to add the `RenameField` operation(s) for any related field names to the operations list:

    class Migration(migrations.Migration):
    
        dependencies = [
            (&#39;myapp&#39;, &#39;0002_rename_fields&#39;),  # &lt;-- is this okay?
        ]
    
        operations = [
            migrations.RenameField(&#39;AnotherModel&#39;, &#39;foo&#39;, &#39;bar&#39;),
            migrations.RenameField(&#39;YetAnotherModel&#39;, &#39;foo&#39;, &#39;bar&#39;)
        ]

Step 8
====

Apply the 2nd migration:

    python manage.py migrate

&lt;hr/&gt;

Aside from updating the rest of the code (views, forms, etc.) to reflect the new variable names, is this basically how the new migration functionality would work?

Also, this seems like a lot of steps. Can the migration operations be condensed in some way?

Thanks!

Django migration strategy for renaming a model and relationship fields

I want to remove null=True from a TextField:

    -    footer=models.TextField(null=True, blank=True)
    +    footer=models.TextField(blank=True, default=&#39;&#39;)

I created a schema migration:

    manage.py schemamigration fooapp --auto

Since some footer columns contain `NULL` I get this `error` if I run the migration:
&gt;django.db.utils.IntegrityError: column &quot;footer&quot; contains null values

I added this to the schema migration:

        for sender in orm[&#39;fooapp.EmailSender&#39;].objects.filter(footer=None):
            sender.footer=&#39;&#39;
            sender.save()

Now I get:

    django.db.utils.DatabaseError: cannot ALTER TABLE &quot;fooapp_emailsender&quot; because it has pending trigger events

What is wrong?

Django-DB-Migrations: cannot ALTER TABLE because it has pending trigger events

As the title says, I can&#39;t seem to get migrations working.

The app was originally under 1.6, so I understand that migrations won&#39;t be there initially, and indeed if I run `python manage.py migrate` I get:

    Operations to perform:
      Synchronize unmigrated apps: myapp
      Apply all migrations: admin, contenttypes, auth, sessions
    Synchronizing apps without migrations:
      Creating tables...
      Installing custom SQL...
      Installing indexes...
    Running migrations:
      No migrations to apply.


If I make a change to any models in `myapp`, it still says unmigrated, as expected.

But if I run `python manage.py makemigrations myapp` I get:

    No changes detected in app &#39;myapp&#39;


Doesn&#39;t seem to matter what or how I run the command, it&#39;s never detecting the app as having changes, nor is it adding any migration files to the app.

Is there any way to force an app onto migrations and essentially say &quot;This is my base to work with&quot; or anything? Or am I missing something?

My database is a PostgreSQL one if that helps at all.

Django 1.7 - makemigrations not detecting changes

I created a new app with some models and now I noticed that some of the models are poorly thought out. As I haven&#39;t committed the code the sensible thing would be to migrate the database to last good state and redo the migration with better models. In this case the last good state is database where the new app doesn&#39;t exist.

How can I migrate back from initial migration in Django 1.7?

In `South` one could do:

    python manage.py migrate &lt;app&gt; zero

Which would clear `&lt;app&gt;` from migration history and drop all tables of `&lt;app&gt;`. 

How to do this with Django 1.7 migrations?

How to migrate back from initial migration in Django 1.7?

Django **1.7** introduced [database migrations][1].

When running the unit tests in Django 1.7, it forces a *migrate*, that takes a long time. So I would like to skip the django migrations, and create the database in the final state.


I know that ignoring the migrations can be a bad practice, as that part of the code would not be tested. But that&#39;s not the case: I&#39;m running the full migrations in the CI test server (jenkins). I only want to skip the migrations in my local tests, where the speed matters.


----------


Some context:

Until Django **1.6**, when using South, I used the [*SOUTH_TESTS_MIGRATE*][2] setting:

&gt; By default, South’s syncdb command will also apply migrations if it’s run in non-interactive mode, which includes when you’re running tests - it will run every migration every time you run your tests.
&gt;
&gt; If you want the test runner to use syncdb instead of migrate - for example, if your migrations are taking way too long to apply - simply set SOUTH_TESTS_MIGRATE = False in settings.py.

However, *syncdb* does not exist anymore, now it&#39;s *migrate*.


And from Django **1.8** I&#39;ll use the *[--keepdb][3]* parameter:

&gt; The --keepdb option can be used to preserve the test database between test runs. This has the advantage of skipping both the create and destroy actions which greatly decreases the time to run tests, especially those in a large test suite. If the test database does not exist, it will be created on the first run and then preserved for each subsequent run. Any unapplied migrations will also be applied to the test database before running the test suite.


So this question is limited to Django 1.7.


  [1]: https://docs.djangoproject.com/en/1.7/topics/migrations/
  [2]: http://south.readthedocs.org/en/latest/unittests.html
  [3]: https://docs.djangoproject.com/en/dev/ref/django-admin/#django-admin-option---keepdb

Disable migrations when running unit tests in Django 1.7

I&#39;m building a fairly simple application, research, in my Django project that uses Django-CMS.  (It&#39;s my first ground-up attempt at a project/application.)  Its main purpose is to store various intellectual assets (i.e article, book, etc. written by a researcher).  

The problem is that when I point the browser to `/research/` I get an error saying that the `table &#39;research_journal&#39; doesn&#39;t exist (&quot;no such table&quot;)`.

I&#39;m using Djnago 1.6.5 with a sqlite3 database.

Looking at `python manage.py sql research` yields:

    BEGIN;
    CREATE TABLE &quot;research_researchbase&quot; (
        &quot;id&quot; integer NOT NULL PRIMARY KEY,
        &quot;pub_date&quot; datetime NOT NULL,
        &quot;authors&quot; varchar(200) NOT NULL,
        &quot;year&quot; varchar(25) NOT NULL,
        &quot;title&quot; varchar(200) NOT NULL,
        &quot;subtitle&quot; varchar(200) NOT NULL,
        &quot;image_id&quot; integer NOT NULL REFERENCES &quot;filer_image&quot; (&quot;file_ptr_id&quot;),
        &quot;link&quot; varchar(200) NOT NULL
    )
    ;
    CREATE TABLE &quot;research_journal&quot; (
        &quot;researchbase_ptr_id&quot; integer NOT NULL PRIMARY KEY REFERENCES &quot;research_researchbase&quot; (&quot;id&quot;),
        &quot;journal&quot; varchar(200) NOT NULL,
        &quot;abstract&quot; text NOT NULL,
        &quot;citation&quot; varchar(200) NOT NULL
    )
    ;
    CREATE TABLE &quot;research_encyclopedia_chapter&quot; (
        &quot;researchbase_ptr_id&quot; integer NOT NULL PRIMARY KEY REFERENCES &quot;research_researchbase&quot; (&quot;id&quot;),
        &quot;encyclopedia&quot; varchar(200) NOT NULL,
        &quot;publisher&quot; varchar(200) NOT NULL,
        &quot;summary&quot; varchar(200) NOT NULL
    )
    ;
    CREATE TABLE &quot;research_book&quot; (
        &quot;researchbase_ptr_id&quot; integer NOT NULL PRIMARY KEY REFERENCES &quot;research_researchbase&quot; (&quot;id&quot;),
        &quot;publisher&quot; varchar(200) NOT NULL,
        &quot;summary&quot; varchar(200) NOT NULL
    )
    ;
    
    COMMIT;

I&#39;ve run `python manage.py migrate research` and get:

    /Users/XXX/Documents/repos/sfs/env/lib/python2.7/site-packages/app_data/fields.py:2: DeprecationWarning: django.utils.simplejson is deprecated; use json instead.
      from django.utils import simplejson as json
    
    Running migrations for research:
    - Nothing to migrate.
     - Loading initial data for research.
    Installed 0 object(s) from 0 fixture(s)

I&#39;ve run `python manage.py syncdb` and get the following:

    Syncing...
    Creating tables ...
    Installing custom SQL ...
    Installing indexes ...
    Installed 0 object(s) from 0 fixture(s)
    
    Synced:
     &gt; djangocms_admin_style
     &gt; django.contrib.auth
     &gt; django.contrib.contenttypes
     &gt; django.contrib.sessions
     &gt; django.contrib.admin
     &gt; django.contrib.sites
     &gt; django.contrib.sitemaps
     &gt; django.contrib.staticfiles
     &gt; django.contrib.messages
     &gt; mptt
     &gt; south
     &gt; sekizai
     &gt; django_select2
     &gt; hvad
    
    Not synced (use migrations):
     - djangocms_text_ckeditor
     - cms
     - menus
     - djangocms_style
     - djangocms_column
     - djangocms_file
     - djangocms_flash
     - djangocms_googlemap
     - djangocms_inherit
     - djangocms_link
     - djangocms_picture
     - djangocms_teaser
     - djangocms_video
     - reversion
     - polls
     - djangocms_polls
     - aldryn_blog
     - easy_thumbnails
     - filer
     - taggit
     - research
    (use ./manage.py migrate to migrate these)

Here&#39;s the `models.py`:

    from django.db import models
    from django.utils import timezone
    from filer.fields.image import FilerImageField
    
    import datetime
    
    class ResearchBase(models.Model):
        pub_date = models.DateTimeField(&#39;date published&#39;)
        authors = models.CharField(max_length=200)
        year = models.CharField(max_length=25)
        title = models.CharField(max_length=200)
        subtitle = models.CharField(max_length=200, blank=True)
        image = FilerImageField()
        link = models.CharField(max_length=200, blank=True)
        
        def __unicode__(self):
            return self.title
        
        def was_published_recently(self):
            return self.pub_date &gt;= timezone.now() - datetime.timedelta(days=1)
            
    
    class Journal(ResearchBase):
        journal = models.CharField(max_length=200)
        abstract = models.TextField()
        citation = models.CharField(max_length=200)
        
        
    class Encyclopedia_Chapter(ResearchBase):
        encyclopedia = models.CharField(max_length=200)
        publisher = models.CharField(max_length=200)
        summary = models.CharField(max_length=200)
        
            
    class Book(ResearchBase):
        publisher = models.CharField(max_length=200)
        summary = models.CharField(max_length=200)

Here&#39;s my `views.py` (note that I am passing two objects through render, ignore the fact that I have yet to include the class Books in the whole deal):

    from django.shortcuts import render, get_object_or_404
    from django.http import HttpResponse, Http404
    from django.template import RequestContext, loader
    
    from research.models import Journal, Encyclopedia_Chapter, Book
    
    def research_index(request):
        latest_journal_list = Journal.objects.order_by(&#39;-pub_date&#39;)[:5]
        latest_chapter_list = Encyclopedia_Chapter.objects.order_by(&#39;-pub_date&#39;)[:5]
        
        context = {
            &#39;latest_journal_list&#39;: latest_journal_list,
            &#39;latest_chapter_list&#39;: latest_chapter_list
        }
        
        return render(request, &#39;research/index.html&#39;, context)
        
    def journal_detail(request, journal_id):
        journal = get_object_or_404(Journal, pk=journal_id)
        return render(request, &#39;research/journal_detail.html&#39;, {&#39;journal&#39;: journal})
        
    def chapter_detail(request, chapter_id):
        chapter = get_object_or_404(Encyclopedia_Chapter, pk=chapter_id)
        return render(request, &#39;research/chapter_detail.html&#39;, {&#39;chapter&#39;: chapter})

Here&#39;s the application&#39;s `url.py`:

    from django.conf.urls import patterns, url
    
    from research import views
    
    urlpatterns = patterns(&#39;&#39;,
        url(r&#39;^$&#39;, views.research_index, name=&#39;research&#39;),
        url(r&#39;^(?P&lt;journal_id&gt;\d+)/$&#39;, views.journal_detail, name=&#39;journal_detail&#39;),
        url(r&#39;^(?P&lt;chapter_id&gt;\d+)/$&#39;, views.chapter_detail, name=&#39;chapter_detail&#39;),
    )

Here&#39;s the `index.html` template:

    {% extends &#39;research/base.html&#39; %}
    
    {% block research_content %}
    
    &lt;div class=&quot;container&quot;&gt;
    	&lt;div class=&quot;row featurette&quot;&gt;
    		&lt;h3 id=&quot;research&quot;&gt;Peer-reviewed Journal Articles&lt;/h3&gt;
    		{% if latest_journal_list %}
    		    &lt;ul id=&quot;research&quot;&gt;
    		    {% for journal in latest_journal_list %}
    		        &lt;li id=&quot;research&quot;&gt;
    							&lt;img src=&quot;{{ journal.image.url }}&quot; id=&quot;research&quot;&gt;
    							&lt;h4&gt;{{ journal.journal }}&lt;/h4&gt;
    							&lt;h5&gt;{{ journal.title }}&lt;/h5&gt;
    							&lt;a href=&quot;{% url &#39;research:journal_detail&#39; journal.id %}&quot;&gt;Read More&lt;/a&gt;
    						&lt;/li&gt;
    		    {% endfor %}
    		    &lt;/ul&gt;
    		{% else %}
    		    &lt;p&gt;No journals are available.&lt;/p&gt;
    		{% endif %}
    	&lt;/div&gt;
    	
    	&lt;div class=&quot;row featurette&quot;&gt;
    		&lt;h3 id=&quot;research&quot;&gt;Encyclopedia Chapters&lt;/h3&gt;
    		{% if latest_chapter_list %}
    		    &lt;ul id=&quot;research&quot;&gt;
    		    {% for chapter in latest_chapter_list %}
    		        &lt;li id=&quot;research&quot;&gt;
    							&lt;img src=&quot;{{ chapter.image.url }}&quot; id=&quot;research&quot;&gt;
    							&lt;h4&gt;{{ chapter.journal }}&lt;/h4&gt;
    							&lt;h5&gt;{{ chapter.title }}&lt;/h5&gt;
    							&lt;a href=&quot;{% url &#39;research:chapter_detail&#39; chapter.id %}&quot;&gt;Read More&lt;/a&gt;
    						&lt;/li&gt;
    		    {% endfor %}
    		    &lt;/ul&gt;
    		{% else %}
    		    &lt;p&gt;No encyclopedia chapters are available.&lt;/p&gt;
    		{% endif %}
    	&lt;/div&gt;
    &lt;/div&gt;
    
    {% endblock %}

Just in case it matters, here&#39;s my `cms_app.py`:

    from cms.app_base import CMSApp
    from cms.apphook_pool import apphook_pool
    from django.utils.translation import ugettext_lazy as _
    
    
    class ResearchApp(CMSApp):
        name = _(&quot;Research App&quot;)
        urls = [&quot;research.urls&quot;]
        app_name = &quot;research&quot;
    
    apphook_pool.register(ResearchApp)



Django: OperationalError No Such Table

There are already similar questions for South, but I have started my project with Django 1.7 and am not using South.

During development a lot of migrations have been created, however the software is not yet delievered and there exists no database that must be migrated. Therefore I would like to reset the migrations as if my current model was the original one and recreate all databases.

What is the recommended way to do that?

EDIT: As of Django 1.8 there is a new command named [squashmigrations][1] which more or less solves the problem described here.


  [1]: https://docs.djangoproject.com/en/1.8/topics/migrations/#squashing-migrations

How to simplify migrations in Django 1.7?

I&#39;ve been a user of Django for about 2 years now and there is a feature I have always been afraid of using : _**faking migrations**_.

I&#39;ve looked pretty much everywhere and the most information I can get is from the [documentation][1] where it states that:

**--fake**

&gt; Tells Django to mark the migrations as having been applied or
&gt; unapplied, but without actually running the SQL to change your
&gt; database schema.
&gt; 
&gt; This is intended for advanced users to manipulate the current
&gt; migration state directly if they’re manually applying changes; be
&gt; warned that using --fake runs the risk of putting the migration state
&gt; table into a state where manual recovery will be needed to make
&gt; migrations run correctly.

**--fake-initial**

&gt; Allows Django to skip an app’s initial migration if all database
&gt; tables with the names of all models created by all CreateModel
&gt; operations in that migration already exist. This option is intended
&gt; for use when first running migrations against a database that
&gt; preexisted the use of migrations. This option does not, however, check
&gt; for matching database schema beyond matching table names and so is
&gt; only safe to use if you are confident that your existing schema
&gt; matches what is recorded in your initial migration.

I get the general idea and why one would want to use this feature. But, I don&#39;t understand the part where it says that this is _**intended for advanced users only.**_

Can someone explain what is happening behind the scene and why manual recovery would be needed. 

**NOTE**  

I&#39;m not looking for the exact raw SQL queries that runs when faking a migration. I&#39;m only looking for a general idea of what is happening behind the scene and maybe an example of why faking a migration
 would result in a state where `makemigrations` would not be working correctly.


  [1]: https://docs.djangoproject.com/en/1.11/ref/django-admin/#cmdoption-migrate-fake

Django migrate --fake and --fake-initial explained

I am trying to apply a migration but am getting the error:

&gt; django.db.utils.OperationalError: (1050, &quot;Table &#39;customers_customer&#39;
&gt; already exists&quot;)

I get this by issuing the following command:

    python manage.py migrate

My customer table already exists, so what do I do to let the migration know this, not error out, and run my modification to my model?


I ran this on my local environment with local database with no problem.  It is when I pointed my database to production and ran `migrate` above that I get this error.

django 1.7 migrate gets error &quot;table already exists&quot;

I added a new, non-nullable field to my Django model and am trying to use migrations to deploy that change. How would I set default value to use for existing models to be some function of those models rather than a constant?

As an example let&#39;s say I previously had a `created_on` field and I just added an `updated_on` field whose value I want to set initially to the model&#39;s `created_on`. How would I do this in a migration?

This is what I am trying to start with:

        migrations.AddField(
            model_name=&#39;series&#39;,
            name=&#39;updated_as&#39;,
            field=models.DateTimeField(default=????, auto_now=True),
            preserve_default=False,
        ),

Django Migrations Add Field with Default as Function of Model

In Django&#39;s migrations code, there&#39;s a `squashmigrations` command which: &quot;Squashes the migrations for `app_label` up to and including `migration_name` down into fewer migrations, if possible.&quot;

So, if you want to squash, say, the first 5 migrations, this will help.

What&#39;s the best way to squash starting with a particular `migration_name`?

In a project I&#39;m currently working on, we&#39;ve added 5-10 new migration files as we&#39;ve added new features. We&#39;ll deploy the whole project at once and it looks like running these individually will take too long. I&#39;d like to squash all the migrations for this project into a single migration and test the time to run that.

How to squash recent Django migrations?

In django 1.8 is there a way to run a specific migration and that migration only.

Not for one app only but a specific file in that apps migrations directory.

EDIT TO ORIGINAL:

        Traceback (most recent call last):
      File &quot;manage.py&quot;, line 10, in &lt;module&gt;
        execute_from_command_line(sys.argv)
      File &quot;/home/vagrant/virtualenvs/aku/lib/python3.4/site-packages/django/core/management/__init__.py&quot;, line 338, in execute_from_command_line
        utility.execute()
      File &quot;/home/vagrant/virtualenvs/aku/lib/python3.4/site-packages/django/core/management/__init__.py&quot;, line 330, in execute
        self.fetch_command(subcommand).run_from_argv(self.argv)
      File &quot;/home/vagrant/virtualenvs/aku/lib/python3.4/site-packages/django/core/management/base.py&quot;, line 393, in run_from_argv
        self.execute(*args, **cmd_options)
      File &quot;/home/vagrant/virtualenvs/aku/lib/python3.4/site-packages/django/core/management/base.py&quot;, line 444, in execute
        output = self.handle(*args, **options)
      File &quot;/home/vagrant/virtualenvs/aku/lib/python3.4/site-packages/django/core/management/commands/migrate.py&quot;, line 146, in handle
        plan = executor.migration_plan(targets)
      File &quot;/home/vagrant/virtualenvs/aku/lib/python3.4/site-packages/django/db/migrations/executor.py&quot;, line 50, in migration_plan
        self.loader.graph.node_map[target].children
    KeyError: (&#39;wagtailcore&#39;, &#39;0001_initial&#39;)


Did a little searching and located this https://code.djangoproject.com/ticket/24225#no1

Django 1.8 Run a specific migration

(I know there is a title the same as this, but the question is different). 

I have managed to get my development machine migrations and production migrations out of sync. 

I have a Django app which was using South. I had my own workflow that worked fine (it probably wasn&#39;t the correct way to do things, but I had no problems with it). 

Basically I have a script that copies the production database dump to my development machine. It also copied the migration files. That way the two were in synch, and I could run South commands as normal. 


Now I have upgraded to 1.7, and started using migrations. When I use my previous workflow (copy database dump, and migration files from production), it is not detecting changes on my development machine.

I have read through the migrations document, and I see that the correct way to use it is to 

 1. run &quot;make migrations&quot; and &quot;migrate&quot; on my development machine.
 2. run &quot;migrate&quot; on my devlopemnt machine to actually make the database changes
 3. Copy changes over, including migration files.
 4. run &quot;migrate&quot; on the production machine. (without the &quot;makemigrations&quot; step)

Anyway. It is all a mess now. I would like to &quot;reset&quot; my migrations and start from scratch, doing things properly from now on.

What do I need to do? 

 1. Delete the contents of the migration table (on both machines)?
 2. Delete the contents of the migration folder? (Including the __init__.py file).  
 3. Start the migrations as per the documentation for a new one.

Have I missed anything?
Is there a reason why copying everything from production(database and migration files) doesn&#39;t detect any changes on my development machine afterwards

How to reset migrations in Django 1.7

My Django project is going to be backed by a large database with several hundred thousand entries, and will need to support searching (I&#39;ll probably end up using djangosearch or a similar project.)

Which database backend is best suited to my project and why? Can you recommend any good resources for further reading?

MySQL vs PostgreSQL? Which should I choose for my Django project?

I started a django 1.8 project, which uses the migrations system.  
Somehow along the way things got messy, so I erased the migrations folders and table from the DB, and now I&#39;m trying to reconstruct them, with no success.  

I have three apps (3 `models.py` files), and the models reflect the tables EXACTLY!  

The best approach that I&#39;ve found so far was:

1. Erase all `migrations` folders. Done!
2. Delete everything from the `django_migrations` table. Done!
3. Run `python manage.py makemigrations --empty &lt;app&gt;` for every app. Done!
4. Run `python manage.py migrate --fake`. Done! (although it works only if I run it after every `makemigrations` command.

Now I add a new field, run the `makemigrations` command, and I receive the following error:  
`django.db.utils.OperationalError: (1054, &quot;Unknown column &#39;accounts_plan.max_item_size&#39; in &#39;field list&#39;&quot;)`  

I&#39;ve been burning HOURS on this thing.  How the h**l can I initialize the migrations so I can continue working without migration interruptions every time?  

Why is it so complicated? Why isn&#39;t there a simple one-liner: `initiate_migrations_from_schema`?

EDIT:  
Now things get even nastier. I truncated the `django_migrations` table and deleted all the `migrations` folder.  
Now I try to run `python manage.py migrate --fake-initial` (something I found in the DEV docs), just so it sets up all of Django&#39;s &#39;internal&#39; apps (auth, session, etc) and I&#39;m getting:  
`(1054, &quot;Unknown column &#39;name&#39; in &#39;django_content_type&#39;&quot;)`.  
Now, this &quot;column&quot; is not a real column. It&#39;s a `@property` defined in Django&#39;s `contenttypes` app. WHAT IS GOING ON HERE? Why is it identifying the `name` property as a real column?

Django 1.8: Create initial migrations for existing schema

In Django, is there an easy way to check whether all database migrations have been run? I&#39;ve found `manage.py migrate --list`, which gives me the information I want, but the format isn&#39;t very machine readable.

For context: I have a script that shouldn&#39;t start running until the database has been migrated. For various reasons, it would be tricky to send a signal from the process that&#39;s running the migrations. So I&#39;d like to have my script periodically check the database to see if all the migrations have run.

Check for pending Django migrations

I&#39;m creating a data migration using the `RunPython` method. However when I try to run a method on the object none are defined. Is it possible to call a method defined on a model using `RunPython`?

Django migrations RunPython not able to call model methods

I have a `uuid` field (not a primary key). The generated migration is:

    from __future__ import unicode_literals
    
    from django.db import migrations, models
    import uuid
    
    
    class Migration(migrations.Migration):
    
        dependencies = [
            ....
        ]
    
        operations = [
            ...
            migrations.AddField(
                model_name=&#39;device&#39;,
                name=&#39;uuid&#39;,
                field=models.UUIDField(default=uuid.uuid4, unique=True),
            ),
            ...
        ]

But when doing `python manage.py migrate` it is crashing with:

&gt; django.db.utils.IntegrityError: could not create unique index
&gt; &quot;restaurants_device_uuid_key&quot; DETAIL:  Key
&gt; (uuid)=(f3858ded-b8e0-4ac0-8436-8a61b10efc73) is duplicated.

Strangely enough, the problem does not seem to occur with primary keys (which are maybe created by the database, and not internally by django?)

How can I add a uuid field, and make sure that migrations work?

Django migration with uuid field generates duplicated values

I have a Django application in which I want to change a field from a ForeignKey to a ManyToManyField.  I want to preserve my old data.  What is the simplest/best process to follow for this?  If it matters, I use sqlite3 as my database back-end. 

If my summary of the problem isn&#39;t clear, here is an example.  Say I have two models:

    class Author(models.Model):  
        author = models.CharField(max_length=100) 
    
    class Book(models.Model):  
        author = models.ForeignKey(Author)  
        title = models.CharField(max_length=100)

  
  
Say I have a lot of data in my database.  Now, I want to change the Book model as follows:

    class Book(models.Model):  
        author = models.ManyToManyField(Author)  
        title = models.CharField(max_length=100) 

 
I don&#39;t want to &quot;lose&quot; all my prior data.  

What is the best/simplest way to accomplish this?   

Ken
 

Django data migration when changing a field to ManyToMany

i&#39;d like to use a view i&#39;ve created in my database as the source for my django-view.

Is this possible, without using custom sql?


***\*\*\*13/02/09 UPDATE***********

Like many of the answers suggest, you can just make your own view in the database and then use it within the API by defining it in models.py.

some warning though:

 - manage.py syncdb will not work anymore
 - the view need the same thing at the start of its name as all the other models(tables) e.g if your app is called &quot;thing&quot; then your view will need to be called thing_$viewname

Can I use a database view as a model in Django?

How would I rerun a data migration on Django 1.8+? If relevant, my migration is numbered 0011_my_data_migration.py and is the latest migration. 

Rerun a Django data migration

Django `runserver` complains:

    You have unapplied migrations; 
    your app may not work properly until they are applied. 
    Run &#39;python manage.py migrate&#39; to apply them.

How can I find out which migrations are unapplied without running migrate?

All Django Migrations Solutions on Gang of Coders

Total of 24 Django Migrations Solutions