On Mon, May 16, 2016 at 10:16 AM, JoeCodeswell <joecodesw...@gmail.com> wrote:
> How can I flush/clear database for single app, i.e. NOT the Project? > > I have a multi-app project. > In a particular app I created my model with single class. > I populated the db for that model with the Admin Interface. > Now i have changed the model to have 2 classes related by a ForeignKey. > I ran makemigrations on that app and it said, "you are trying to add a > non-nullable field 'song' to part without a default; we can't do that (the > database needs something to populate existing rows)." > I don't want to keep the existing populated tables for that app. > How can i start over for that app? > I can see this happening again and again for me. > Erik's answer is correct because it answers the question you specifically asked. You would need to delete all instances (rows) for any models that are part of your app, either manually or as part of a data migration. Keep in mind that if your models interact with other apps (ie, foreign keys pointing at Group or User from django.contrib), you may be left with orphaned and/or incomplete data if your app FK's do not use on_delete=models.CASCADE (which is the current default, but will not be in upcoming Django releases [1]). Probably won't be an issue, but is something to keep in mind. I'm guessing that you are still in the initial development stages of your app. Your actual question is likely "how do I keep Django from pestering me about non-nullable fields while I'm doing my development updates?" The best answer is "you can't without a bit of work for each new field". Every time you add a new non-nullable field with no default to a subsequent migration, you'll get this question. Even if you wipe out all of the instances as Erik pointed out, you'll still get asked this question because the migration process does not check whether or not a table contains existing data prior to asking for a default value for your new non-nullable field, intentionally [2]. The only way to avoid it would be to set a default= for the field (either a static value or a callable). You should also have a look here [3]. Django provides some guidance on dealing with non-nullable fields, with extra help for those fields that also have unique=True (where a single static default value will not work). Another option would be a customized set of migrations. An example can be found here [4]. Yet another option (since you don't care to keep the data), would be to try a 'zero' migration specific to your app first, which will remove (reverse?) all migrations related to that app (manage.py migrate myapp zero). [5] After that, you can probably run your app migration normally. I'm guessing that all of your migrations would need to be reversible for this to work, which is likely if you haven't customized the migrations for your app. I've never tried it myself. Keep a copy of the DB in the event things go sideways if you care to keep your other data intact. 1. https://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.ForeignKey.on_delete 2. https://code.djangoproject.com/ticket/21896 3. https://docs.djangoproject.com/en/1.9/howto/writing-migrations/#migrations-that-add-unique-fields 4. http://stackoverflow.com/a/28012607 5. https://docs.djangoproject.com/en/1.9/ref/django-admin/#migrate HTH, -James -- 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/CA%2Be%2BciUyF7FaKm2N8goGwudbzqTLysvdcPnkPfOdHoMujCe1kg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
