# Makemigration fail - no such table - during active development **URL:** \ **Category:** Getting Started\ **Created:** [July 24, 2023, 3:05am UTC](https://forum.djangoproject.com/t/makemigration-fail-no-such-table-during-active-development/22511 "2023-07-24T03:05:34Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![apax](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/apax/32/10484_2.png) [@apax](https://forum.djangoproject.com/u/apax)\ **Post date:** [July 24, 2023, 3:05am UTC](https://forum.djangoproject.com/t/makemigration-fail-no-such-table-during-active-development/22511/1 "2023-07-24T03:05:34Z")
Recently, I’m refactoring my code to add a new field to a model. After adding the new field, I went to “makemigrations” and starting getting failures. After numerous attempts at trying to fix, I decided to use a hammer: I deleted db.sqllite3 to re-create. I was not able to resolve the problem with creating a new DB. I then removed all my migrations files and the db.sqllite3 file to create anew. Now, when I attempt to “makemigrations” from scratch, I’m getting a “no such table” from a reference in forms.py to a model that should be created in migrations. However, it’s a chicken-before-egg problem. I need to create a migration file to create the table, but makemigrations fails because there’s no table? How can I solve for this? Thanks! Django 4.2.2 Python 3.9.6 > python manage.py makemigrations batchthis > … [snipped]… > File “/Users/aaronpaxson/PycharmProjects/webroot/batchthis/forms.py”, line 48, in > class BatchAddForm(forms.Form): > File “/Users/aaronpaxson/PycharmProjects/webroot/batchthis/forms.py”, line 54, in BatchAddForm > size\_units = forms.ChoiceField(choices=units, required=True) > …[snipped]… > django.db.utils.OperationalError: no such table: batchthis\_unit snipped forms.py … from .models import Unit units = Unit.objects.filter(category=Unit.VOLUME).values\_list(‘id’,‘name’) size\_units = forms.ChoiceField(choices=units, required=True) … ---
**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\ **Post date:** [July 24, 2023, 3:24am UTC](https://forum.djangoproject.com/t/makemigration-fail-no-such-table-during-active-development/22511/2 "2023-07-24T03:24:38Z")
If you’re creating a new database, you need to run the current migrations before doing a makemigrations to create new migrations. ---
**Author:** ![shangxiao](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/shangxiao/32/10313_2.png) [@shangxiao](https://forum.djangoproject.com/u/shangxiao)\ **Post date:** [July 24, 2023, 3:30am UTC](https://forum.djangoproject.com/t/makemigration-fail-no-such-table-during-active-development/22511/3 "2023-07-24T03:30:05Z")
Edit: ah it’s below that, yes please don’t do module level db access. ```auto File “/Users/aaronpaxson/PycharmProjects/webroot/batchthis/forms.py”, line 54, in BatchAddForm size_units = forms.ChoiceField(choices=units, required=True) ``` What’s `units` here? Is it a _ **materialised** _ queryset? If so then that’s a no-no (module-level aka import time db access). Probably only just got highlighted now after truncating your db. ---
**Author:** ![apax](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/apax/32/10484_2.png) [@apax](https://forum.djangoproject.com/u/apax)\ **Post date:** [July 24, 2023, 3:50am UTC](https://forum.djangoproject.com/t/makemigration-fail-no-such-table-during-active-development/22511/4 "2023-07-24T03:50:17Z")
Running “migrate” or “makemigrations” results in the same problem. ---
**Author:** ![apax](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/apax/32/10484_2.png) [@apax](https://forum.djangoproject.com/u/apax)\ **Post date:** [July 24, 2023, 3:52am UTC](https://forum.djangoproject.com/t/makemigration-fail-no-such-table-during-active-development/22511/5 "2023-07-24T03:52:59Z")
“Unit” is a model. “units” is a list of filtered Unit items. forms.py units = Unit.objects.filter(category=Unit.VOLUME).values\_list(‘id’,‘name’) ---
**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\ **Post date:** [July 24, 2023, 4:06am UTC](https://forum.djangoproject.com/t/makemigration-fail-no-such-table-during-active-development/22511/6 "2023-07-24T04:06:43Z")
Is that line in a method or function within forms.py, or is it module level code? If it’s at the module level (not within a function), then that’s what’s causing the error. ---
**Author:** ![apax](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/apax/32/10484_2.png) [@apax](https://forum.djangoproject.com/u/apax)\ **Post date:** [July 24, 2023, 4:11am UTC](https://forum.djangoproject.com/t/makemigration-fail-no-such-table-during-active-development/22511/7 "2023-07-24T04:11:26Z")
Unfortunately, I may not be saavy enough to know the difference. I have a form that leverages data in a model (table) called Units: forms.py (snipped) ```auto from .models import Unit class BatchAddForm(forms.Form): units = Unit.objects.filter(category=Unit.VOLUME).values_list('id','name') fermenters_ready = Fermenter.objects.filter(vessel__status=Vessel.STATUS_READY).values_list('id','vessel__name') name = forms.CharField(widget=forms.TextInput(attrs={'placeholder':'Name of Batch'}),required=True) startdate = forms.DateField(label="Start Date",widget=NumberInput(attrs={'type':'date'}),required=True) size = forms.IntegerField(widget=forms.TextInput(attrs={'placeholder':'Size of batch'}),required=True) size_units = forms.ChoiceField(choices=units, required=True) ``` Now, we are picking on “Unit” here, because it’s the first that’s found as an error. If I remove/comment it out, another model/table is found to be “not found”. I believe it’s because I can’t initialize the database with the tables, because I’m getting an error saying “table not found”? I realize I used a hammer here, where I probably could have been more surgical (i.e not removing my DB and migrations), but I’ve had so many changes, I thought it would be cleaner to start with a fresh migration list. I’m now regretting that. ---
**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\ **Post date:** [July 24, 2023, 4:15am UTC](https://forum.djangoproject.com/t/makemigration-fail-no-such-table-during-active-development/22511/8 "2023-07-24T04:15:14Z")
A form defined fields - you don’t use queries for form fields. So no, those two lines for `units` and `fermenters_ready` aren’t valid. I’m not sure what you’re trying to do with those two lines, but whatever it is, this isn’t the way to do it. > [@apax](#): > > I believe it’s because I can’t initialize the database with the tables, because I’m getting an error saying “table not found”? No, that’s not correct. You’ve got cause & effect reversed. You can’t run migrations because those two statements aren’t correct. ---
**Author:** ![apax](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/apax/32/10484_2.png) [@apax](https://forum.djangoproject.com/u/apax)\ **Post date:** [July 24, 2023, 4:18am UTC](https://forum.djangoproject.com/t/makemigration-fail-no-such-table-during-active-development/22511/9 "2023-07-24T04:18:03Z")
hmmmm, I may need to re-read the docs. I have a form that displays only active fermenters. In order to do that, I have to query which fermenters are active to give a valid choice. It was working perfectly fine until I wiped the DB. So, If I’m not supposed to make model query/filters in my form choices, I’m guessing I move that logic my views? That’s all I need to do? ---
**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\ **Post date:** [July 24, 2023, 4:25am UTC](https://forum.djangoproject.com/t/makemigration-fail-no-such-table-during-active-development/22511/10 "2023-07-24T04:25:19Z")
No, you need to reread the forms docs regarding choices for select fields. See [ChoiceField](https://docs.djangoproject.com/en/4.2/ref/forms/fields/#choicefield) and [ModelChoiceField](https://docs.djangoproject.com/en/4.2/ref/forms/fields/#modelchoicefield) along with the links in those sections of the docs. You can also search the forums here for similar topics - this is an area that has been discussed here fairly frequently. ---
**Author:** ![apax](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/apax/32/10484_2.png) [@apax](https://forum.djangoproject.com/u/apax)\ **Post date:** [July 24, 2023, 1:04pm UTC](https://forum.djangoproject.com/t/makemigration-fail-no-such-table-during-active-development/22511/11 "2023-07-24T13:04:22Z")
Thanks @KenWhitesell . i’ll read up. I appreciate it. I have a feeling that’s what @shangxiao was also telling me, but wasn’t following. The docs are great, but knowing the “why” isn’t always there. You can tell I code until it doesn’t work, then read/learn, and continue coding. I imagine this was never a problem for me, since the table did exist by the time I wrote this. ---
**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\ **Post date:** [July 24, 2023, 8:01pm UTC](https://forum.djangoproject.com/t/makemigration-fail-no-such-table-during-active-development/22511/12 "2023-07-24T20:01:25Z")
A lot of the “whys” you are likely encountered are “because Python does it that way”. It’s really tough to understand forms, models, etc, unless you have a really firm understanding of how Python works with classes and modules. The Django docs do assume a degree of proficiency with Python. ---
**Author:** ![apax](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/apax/32/10484_2.png) [@apax](https://forum.djangoproject.com/u/apax)\ **Post date:** [July 24, 2023, 9:38pm UTC](https://forum.djangoproject.com/t/makemigration-fail-no-such-table-during-active-development/22511/13 "2023-07-24T21:38:10Z")
I’m pretty proficient with Python (well, subjective to me, anyway. I’m not a full-time developer, but often enough). Been doing it off-and-on for years, since I dropped Java and EJBs back in 2007. What I didn’t consider, was that Django’s “makemigration” was far more than just “map model to DB”. I didn’t realize it compiled all of the project and validating. I thought it was a simple command that manages the diff for the database, and creates the necessary SQL to build the schema. I’m used to more abstraction where I can call queries from anywhere, I wasn’t intending to give a negative feedback on the docs. But, knowing why lazy calls were important here would have been neat. LOL All good. I’ll refactor my forms knowing this. As I said, it wasn’t a problem for a long time, since the table was there with data while I’ve been coding. Glad I wiped the DB then to catch this. Thanks for the help! ---
**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\ **Post date:** [July 24, 2023, 9:43pm UTC](https://forum.djangoproject.com/t/makemigration-fail-no-such-table-during-active-development/22511/14 "2023-07-24T21:43:42Z")
> [@apax](#): > > I didn’t realize it compiled all of the project and validating. That’s actually not a valid statement. The makemigration command imports your models.py files in the apps that are managed by migrations. (There may be some other imports as well, I’m not entirely sure.) Any other side effects occur as a result of those imports.