Django-makemigrations-未检测到更改

问题:Django-makemigrations-未检测到更改

我试图使用makemigrations命令在现有应用程序中创建迁移,但输出“未检测到更改”。

通常,我使用startapp命令创建新应用,但在创建该应用时并未将其用于该应用。

调试后,我发现它没有创建迁移,因为migrations应用程序中缺少软件包/文件夹。

如果不存在该文件夹,还是创建丢失的文件夹,会更好吗?

I was trying to create migrations within an existing app using the makemigrations command but it outputs “No changes detected”.

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?


回答 0

要为应用创建初始迁移,请运行makemigrations并指定应用名称。将创建迁移文件夹。

./manage.py makemigrations <myapp>

您的应用必须首先包含INSTALLED_APPS(在settings.py内部)。

To create initial migrations for an app, run makemigrations and specify the app name. The migrations folder will be created.

./manage.py makemigrations <myapp>

Your app must be included in INSTALLED_APPS first (inside settings.py).


回答 1

我的问题(以及解决方案)与上述问题有所不同。

我没有使用models.py文件,而是创建了一个models目录并在my_model.py其中创建了文件,并在其中放置了模型。Django找不到我的模型,因此它写道没有要应用的迁移。

我的解决方案是:在my_app/models/__init__.py文件中添加以下行: from .my_model import MyModel

My problem (and so solution) was yet different from those described above.

I wasn’t using models.py file, but created a models directory and created the my_model.py file there, where I put my model. Django couldn’t find my model so it wrote that there are no migrations to apply.

My solution was: in the my_app/models/__init__.py file I added this line: from .my_model import MyModel


回答 2

django在makemigrations命令执行期间未检测到要迁移的内容有多种可能的原因。

  1. 迁移文件夹您的应用程序中需要一个迁移软件包。
  2. INSTALLED_APPS您需要在INSTALLED_APPS.dict中指定您的应用
  3. 详尽度 从运行makemigrations -v 3冗长开始。这可能会为这个问题提供一些启示。
  4. 完整路径INSTALLED_APPS建议指定完整的模块应用程序配置路径“apply.apps.MyAppConfig”
  5. –settings,您可能需要确保设置了正确的设置文件:manage.py makemigrations --settings mysite.settings
  6. 指定应用程序名称可以显式地放入应用程序名称manage.py makemigrations myapp-不仅可以缩小应用程序的迁移范围,而且可以帮助您隔离问题。
  7. 模型元检查你有合适的app_label模型中的元

  8. 调试django调试django核心脚本。makemigrations命令非常简单。这是在pycharm中执行的方法。相应地改变你的脚本定义(例如:makemigrations --traceback myapp

多个数据库:

  • DB路由器时使用Django DB路由器,路由器类(您的自定义类路由器)工作需要实现的allow_syncdb方法。

makemigrations总是为模型更改创建迁移,但是如果allow_migrate()返回False,

There are multiple possible reasons for django not detecting what to migrate during the makemigrations command.

  1. migration folder You need a migrations package in your app.
  2. INSTALLED_APPS You need your app to be specified in the INSTALLED_APPS .dict
  3. Verbosity start by running makemigrations -v 3 for verbosity. This might shed some light on the problem.
  4. Full path In INSTALLED_APPS it is recommended to specify the full module app config path ‘apply.apps.MyAppConfig’
  5. –settings you might want to make sure the correct settings file is set: manage.py makemigrations --settings mysite.settings
  6. specify app name explicitly put the app name in manage.py makemigrations myapp – that narrows down the migrations for the app alone and helps you isolate the problem.
  7. model meta check you have the right app_label in your model meta

  8. Debug django debug django core script. makemigrations command is pretty much straight forward. Here’s how to do it in pycharm. change your script definition accordingly (ex: makemigrations --traceback myapp)

Multiple databases:

  • Db Router when working with django db router, the router class (your custom router class) needs to implement the allow_syncdb method.

makemigrations always creates migrations for model changes, but if allow_migrate() returns False,


回答 3

我已经读过许多关于这个问题的答案,通常说它们只是makemigrations以其他方式运行。但是对我来说,问题出在Meta模型的子类中。

我有一个应用程序配置说label = <app name>(在apps.py文件中models.pyviews.py等等)。如果您的元类碰巧没有与应用程序标签相同的标签(例如,因为您将一个太大的应用程序拆分为多个应用程序),则不会检测到任何更改(也不会显示任何有用的错误消息)。因此,在我的模型课中,我现在有:

class ModelClassName(models.Model):

    class Meta:
        app_label = '<app name>' # <-- this label was wrong before.

    field_name = models.FloatField()
    ...

在此处运行Django 1.10。

I’ve read many answers to this question often stating to simply run makemigrations in some other ways. But to me, the problem was in the Meta subclass of models.

I have an app config that says label = <app name> (in the apps.py file, beside models.py, views.py etc). If by any chance your meta class doesn’t have the same label as the app label (for instance because you are splitting one too big app into multiple ones), no changes are detected (and no helpful error message whatsoever). So in my model class I have now:

class ModelClassName(models.Model):

    class Meta:
        app_label = '<app name>' # <-- this label was wrong before.

    field_name = models.FloatField()
    ...

Running Django 1.10 here.


回答 4

这是一个评论,但可能应该是一个答案。

确保您的应用程序名称位于settings.py中,INSTALLED_APPS否则无论执行什么操作都不会运行迁移。

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',

    'blog',
]

然后运行:

./manage.py makemigrations blog

It is a comment but should probably be an answer.

Make sure that your app name is in settings.py INSTALLED_APPS otherwise no matter what you do it will not run the migrations.

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',

    'blog',
]

Then run:

./manage.py makemigrations blog

回答 5

我还有另一个这里未描述的问题,这让我发疯。

class MyModel(models.Model):
    name = models.CharField(max_length=64, null=True)  # works
    language_code = models.CharField(max_length=2, default='en')  # works
    is_dumb = models.BooleanField(default=False),  # doesn't work

在复制和粘贴的一行中,我有一个尾随的“,”。is_dumb所在的行不会使用’./manage.py makemigrations’创建模型迁移,但也不会引发错误。删除“后,”它按预期方式工作。

因此,在复制粘贴时请多加注意:-)

I had another problem not described here, which drove me nuts.

class MyModel(models.Model):
    name = models.CharField(max_length=64, null=True)  # works
    language_code = models.CharField(max_length=2, default='en')  # works
    is_dumb = models.BooleanField(default=False),  # doesn't work

I had a trailing ‘,’ in one line perhaps from copy&paste. The line with is_dumb doesn’t created a model migration with ‘./manage.py makemigrations’ but also didn’t throw an error. After removing the ‘,’ it worked as expected.

So be careful when you do copy&paste :-)


回答 6

有时./manage.py makemigrations有优于./manage.py makemigrations <myapp>因为它可以处理应用程序之间的某些冲突。

这些场合默默发生,花了几个小时swearing才能理解恐惧的真正含义No changes detected消息。

因此,使用以下命令是一个更好的选择:

./manage.py makemigrations <myapp1> <myapp2> ... <myappN>

There are sometimes when ./manage.py makemigrations is superior to ./manage.py makemigrations <myapp> because it can handle certain conflicts between apps.

Those occasions occur silently and it takes several hours of swearing to understand the real meaning of the dreaded No changes detected message.

Therefore, it is a far better choice to make use of the following command:

./manage.py makemigrations <myapp1> <myapp2> ... <myappN>


回答 7

我从django外部复制了一个表,默认将Meta类设置为“ managed = false”。例如:

class Rssemailsubscription(models.Model):
    id = models.CharField(primary_key=True, max_length=36)
    ...
    area = models.FloatField('Area (Sq. KM)', null=True)

    class Meta:
        managed = False
        db_table = 'RSSEmailSubscription'

通过将managed更改为True,makemigrations开始接受更改。

I had copied a table in from outside of django and the Meta class defaulted to “managed = false”. For example:

class Rssemailsubscription(models.Model):
    id = models.CharField(primary_key=True, max_length=36)
    ...
    area = models.FloatField('Area (Sq. KM)', null=True)

    class Meta:
        managed = False
        db_table = 'RSSEmailSubscription'

By changing manged to True, makemigrations started picking up changes.


回答 8

  1. 确保您的应用在settings.py中的installed_apps中被提及
  2. 确保您的模型类扩展了模型。
  1. Make sure your app is mentioned in installed_apps in settings.py
  2. Make sure you model class extends models.Model

回答 9

我这样做来解决了这个问题:

  1. 擦除“ db.sqlite3”文件。这里的问题是您当前的数据库将被删除,因此您将不得不重新制作它。
  2. 在已编辑的应用程序的迁移文件夹中,删除上次更新的文件。请记住,第一个创建的文件是:“ 0001_initial.py”。例如:我创建了一个新类,并通过“ makemigrations”和“ migrate”过程进行了注册,现在创建了一个名为“ 0002_auto_etc.py”的新文件;删除它。
  3. 转到pycache ”文件夹(位于migrations文件夹内),然后删除文件“ 0002_auto_etc.pyc”。
  4. 最后,转到控制台并使用“ python manage.py makemigrations”和“ python manage.py migration”。

I solved that problem by doing this:

  1. Erase the “db.sqlite3” file. The issue here is that your current data base will be erased, so you will have to remake it again.
  2. Inside the migrations folder of your edited app, erase the last updated file. Remember that the first created file is: “0001_initial.py”. For example: I made a new class and register it by the “makemigrations” and “migrate” procedure, now a new file called “0002_auto_etc.py” was created; erase it.
  3. Go to the “pycache” folder (inside the migrations folder) and erase the file “0002_auto_etc.pyc”.
  4. Finally, go to the console and use “python manage.py makemigrations” and “python manage.py migrate”.

回答 10

我忘了提出正确的论点:

class LineInOffice(models.Model):   # here
    addressOfOffice = models.CharField("Корхоная жош",max_length= 200)   #and here
    ...

在models.py中,然后就开始消除烦人的

在应用程序“ myApp”中未检测到更改

I forgot to put correct arguments:

class LineInOffice(models.Model):   # here
    addressOfOffice = models.CharField("Корхоная жош",max_length= 200)   #and here
    ...

in models.py and then it started to drop that annoying

No changes detected in app ‘myApp ‘


回答 11

另一个可能的原因是,如果您在其他文件中(而不是在程序包中)定义了某些模型,而在其他任何地方都没有引用过。

对我来说,简单地增加from .graph_model import *,以admin.py(其中graph_model.py为新文件)解决了这一问题。

Another possible reason is if you had some models defined in another file (not in a package) and haven’t referenced that anywhere else.

For me, simply adding from .graph_model import * to admin.py (where graph_model.py was the new file) fixed the problem.


回答 12

我的问题比上面的答案要简单得多,并且可能是一个更普遍的原因,只要您的项目已经建立并可以运行。在我的一个已经使用了很长时间的应用程序中,迁移似乎很困难,因此,我急着做了以下事情:

rm -r */migrations/*
rm db.sqlite3
python3 manage.py makemigrations
No changes detected

哇?

我错误地还删除了所有__init__.py文件:(-进入后,一切又恢复正常了:

touch ads1/migrations/__init__.py

对于我的每个应用程序,都可以makemigrations再次使用。

事实证明,我已经手动通过复制另一个创建了一个新的应用程序,忘了把__init__.pymigrations文件夹和confinved我,一切都是靠不住的-我的领先使得它与更坏rm -r如上所述。

希望这可以帮助某人在几个小时内发誓“未检测到更改”错误。

My problem was much simpler than the above answers and probably a far more common reason as long as your project is already set up and working. In one of my applications that had been working for a long time, migrations seemed wonky, so in a hurry, I did the following:

rm -r */migrations/*
rm db.sqlite3
python3 manage.py makemigrations
No changes detected

Whaat??

I had mistakenly also removed all the __init__.py files :( – Everything was working again after I went in and:

touch ads1/migrations/__init__.py

For each of my applications then the makemigrations worked again.

It turns out that I had manually created a new application by copying another and forgot to put the __init__.py in the migrations folder and that confinved me that everything was wonky – leading my making it worse with an rm -r as described above.

Hope this helps someone from swearing at the “No changes detected” error for a few hours.


回答 13

解决方案是您必须将您的应用程序包含在INSTALLED_APPS中。

我错过了,发现了同样的问题。

指定我的应用名称后,迁移成功

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'boards',
]

请注意,我最后提到的木板是我的应用名称。

The solution is you have to include your app in INSTALLED_APPS.

I missed it and I found this same issue.

after specifying my app name migration became successful

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'boards',
]

please note I mentioned boards in last, which is my app name.


回答 14

INSTALLED_APPS = [

'blog.apps.BlogConfig',
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',

]

确保“ blog.apps.BlogConfig”(此设置包含在settings.py中,以便进行应用迁移)

然后运行python3 manage.py makemigrations博客或您的应用名称

INSTALLED_APPS = [

'blog.apps.BlogConfig',
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',

]

make sure ‘blog.apps.BlogConfig’, (this is included in your settings.py in order to make your app migrations)

then run python3 manage.py makemigrations blog or your app name


回答 15

您可能还会遇到的一个非常愚蠢的问题是class Meta在模型中定义两个。在这种情况下,运行时不会应用对第一个所做的任何更改makemigrations

class Product(models.Model):
    somefield = models.CharField(max_length=255)
    someotherfield = models.CharField(max_length=255)

    class Meta:
        indexes = [models.Index(fields=["somefield"], name="somefield_idx")]

    def somefunc(self):
        pass

    # Many lines...

    class Meta:
        indexes = [models.Index(fields=["someotherfield"], name="someotherfield_idx")]

A very dumb issue you can have as well is to define two class Meta in your model. In that case, any change to the first one won’t be applied when running makemigrations.

class Product(models.Model):
    somefield = models.CharField(max_length=255)
    someotherfield = models.CharField(max_length=255)

    class Meta:
        indexes = [models.Index(fields=["somefield"], name="somefield_idx")]

    def somefunc(self):
        pass

    # Many lines...

    class Meta:
        indexes = [models.Index(fields=["someotherfield"], name="someotherfield_idx")]

回答 16

我知道这是一个老问题,但是我整天都在同一个问题上作斗争,而我的解决方案很简单。

我的目录结构类似于…

apps/
   app/
      __init__.py
      app_sub1/
           __init__.py
           models.py
      app_sub2/
           __init__.py
           models.py
      app_sub3/
           __init__.py
           models.py
   app2/
      __init__.py
      app2_sub1/
           __init__.py
           models.py
      app2_sub2/
           __init__.py
           models.py
      app2_sub3/
           __init__.py
           models.py
    main_app/
      __init__.py
      models.py

而且由于直到我遇到问题的所有其他模型都被导入到其他地方,最后又从main_app那里导入了INSTALLED_APPS,所以我很幸运,他们都可以使用。

但是由于我只添加了一个appINSTALLED_APPS而不是app_sub*当我最终添加了一个其他未导入的新模型文件时添加的,因此Django完全忽略了它。

我的解决方法是像这样将models.py文件添加到每个文件的基本目录中app

apps/
   app/
      __init__.py
      models.py <<<<<<<<<<--------------------------
      app_sub1/
           __init__.py
           models.py
      app_sub2/
           __init__.py
           models.py
      app_sub3/
           __init__.py
           models.py
   app2/
      __init__.py
      models.py <<<<<<<<<<--------------------------
      app2_sub1/
           __init__.py
           models.py
      app2_sub2/
           __init__.py
           models.py
      app2_sub3/
           __init__.py
           models.py
    main_app/
      __init__.py
      models.py

然后添加from apps.app.app_sub1 import *等等到每个app关卡models.py文件中。

Bleh …这花了我很长时间才弄清楚,我在任何地方都找不到解决方案…我什至转到了Google搜索结果的第2页。

希望这对某人有帮助!

I know this is an old question but I fought with this same issue all day and my solution was a simple one.

I had my directory structure something along the lines of…

apps/
   app/
      __init__.py
      app_sub1/
           __init__.py
           models.py
      app_sub2/
           __init__.py
           models.py
      app_sub3/
           __init__.py
           models.py
   app2/
      __init__.py
      app2_sub1/
           __init__.py
           models.py
      app2_sub2/
           __init__.py
           models.py
      app2_sub3/
           __init__.py
           models.py
    main_app/
      __init__.py
      models.py

And since all the other models up until the one I had a problem with were being imported somewhere else that ended up importing from main_app which was registered in the INSTALLED_APPS, I just got lucky that they all worked.

But since I only added each app to INSTALLED_APPS and not the app_sub* when I finally added a new models file that wasn’t imported ANYWHERE else, Django totally ignored it.

My fix was adding a models.py file to the base directory of each app like this…

apps/
   app/
      __init__.py
      models.py <<<<<<<<<<--------------------------
      app_sub1/
           __init__.py
           models.py
      app_sub2/
           __init__.py
           models.py
      app_sub3/
           __init__.py
           models.py
   app2/
      __init__.py
      models.py <<<<<<<<<<--------------------------
      app2_sub1/
           __init__.py
           models.py
      app2_sub2/
           __init__.py
           models.py
      app2_sub3/
           __init__.py
           models.py
    main_app/
      __init__.py
      models.py

and then add from apps.app.app_sub1 import * and so on to each of the app level models.py files.

Bleh… this took me SO long to figure out and I couldn’t find the solution anywhere… I even went to page 2 of the google results.

Hope this helps someone!


回答 17

根据官方文档中的“迁移”部分,我在django 3.0中遇到了类似的问题,运行它足以更新我的表结构:

python manage.py makemigrations
python manage.py migrate

但是输出始终是相同的:执行“ makemigrations”脚本后,模型“未检测到更改”。我要在数据库上更新的模型在models.py上出现语法错误:

field_model : models.CharField(max_length=255, ...)

代替:

field_model = models.CharField(max_length=255, ...)

解决了这个愚蠢的错误,使用这些命令可以顺利进行迁移。也许这可以帮助某人。

I had a similar issue with django 3.0, according migrations section in the official documentation, running this was enough to update my table structure:

python manage.py makemigrations
python manage.py migrate

But the output was always the same: ‘no change detected’ about my models after I executed ‘makemigrations’ script. I had a syntax error on models.py at the model I wanted to update on db:

field_model : models.CharField(max_length=255, ...)

instead of:

field_model = models.CharField(max_length=255, ...)

Solving this stupid mistake, with those command the migration was done without problems. Maybe this helps someone.


回答 18

您应该添加polls.apps.PollsConfigINSTALLED_APPSsetting.py

You should add polls.apps.PollsConfig to INSTALLED_APPS in setting.py


回答 19

就我而言,我忘记插入类参数

错误:

class AccountInformation():

正确

class AccountInformation(models.Model):

In my case i forgot to insert the class arguments

Wrong:

class AccountInformation():

Correct

class AccountInformation(models.Model):

回答 20

就我而言,我首先向模型添加了一个字段,而Django说没有任何变化。

比起我决定更改模型的“表名”,makemigrations起作用了。比起将表名改回默认值,新字段也在那里。

django迁移系统中有一个“ bug”,有时看不到新字段。可能与日期字段有关。

In my case, I first added a field to the model, and Django said there’re no changes.

Than I decided to change the “table name” of the model, makemigrations worked. Than I changed table name back to default, and the new field was also there.

There is a “bug” in django migration system, sometimes it doesn’t see the new field. Might be related with date field.


回答 21

可能的原因可能是删除了现有的db文件和migrations文件夹,您可以使用python manage.py makemigrations <app_name>来工作。我曾经遇到过类似的问题。

The possible reason could be deletion of the existing db file and migrations folder you can use python manage.py makemigrations <app_name> this should work. I once faced a similar problem.


回答 22

另一种边缘情况和解决方案:

我添加了一个布尔字段,并同时添加了一个引用该属性的@property,其名称相同(doh)。注释了该属性,并且迁移看到并添加了新字段。重命名该属性,一切都很好。

One more edge case and solution:

I added a boolean field, and at the same time added an @property referencing it, with the same name (doh). Commented the property and migration sees and adds the new field. Renamed the property and all is good.


回答 23

如果您拥有managed = True模型内部元数据,则需要将其删除并进行迁移。然后再次运行迁移,它将检测到新更新。

If you have the managed = True in yout model Meta, you need to remove it and do a migration. Then run the migrations again, it will detect the new updates.


回答 24

将新模型添加到django api应用程序并运行python manage.py makemigrations该工具时,未检测到任何新模型。

奇怪的是,旧模型确实被选中了makemigrations,但这是因为它们在urlpatterns链中并且该工具以某种方式检测到了它们。因此,请注意该行为。

问题是因为与models包相对应的目录结构具有子包,并且所有__init__.py文件均为空。他们必须在每个子文件夹和模型中 显式导入所有必需的类,以__init__.py供Django使用该makemigrations工具将其提取。

models
  ├── __init__.py          <--- empty
  ├── patient
     ├── __init__.py      <--- empty
     ├── breed.py
     └── ...
  ├── timeline
     ├── __init__.py      <-- empty
     ├── event.py
     └── ...

When adding new models to the django api application and running the python manage.py makemigrations the tool did not detect any new models.

The strange thing was that the old models did got picked by makemigrations, but this was because they were referenced in the urlpatterns chain and the tool somehow detected them. So keep an eye on that behavior.

The problem was because the directory structure corresponding to the models package had subpackages and all the __init__.py files were empty. They must explicitly import all the required classes in each subfolder and in the models __init__.py for Django to pick them up with the makemigrations tool.

models
  ├── __init__.py          <--- empty
  ├── patient
  │   ├── __init__.py      <--- empty
  │   ├── breed.py
  │   └── ...
  ├── timeline
  │   ├── __init__.py      <-- empty
  │   ├── event.py
  │   └── ...

回答 25

尝试在admin.py中注册模型,这是一个示例:-admin.site.register(YourModelHere)

您可以执行以下操作:1. 1. admin.site.register(YourModelHere)#在admin.py中2.重新加载页面并重试3.按下CTRL-S并保存4.可能有错误,特别是检查模型.py和admin.py5。或者,在结束时,只需重新启动服务器即可。

Try registering your model in admin.py, here’s an example:- admin.site.register(YourModelHere)

You can do the following things:- 1. admin.site.register(YourModelHere) # In admin.py 2. Reload the page and try again 3. Hit CTRL-S and save 4. There might be an error, specially check models.py and admin.py 5. Or, at the end of it all just restart the server


回答 26

这可能希望对其他人有所帮助,因为我最终花了数小时试图将其消除。

如果你有一个函数模型由同一个名字,这将删除值。事后看来很明显,但仍然如此。

因此,如果您有这样的事情:

class Foobar(models.Model):
    [...]
    something = models.BooleanField(default=False)

    [...]
    def something(self):
        return [some logic]

在这种情况下,该功能将覆盖上面的设置,使其对变为“不可见” makemigrations

This might hopefully help someone else, as I ended up spending hours trying to chase this down.

If you have a function within your model by the same name, this will remove the value. Pretty obvious in hindsight, but nonetheless.

So, if you have something like this:

class Foobar(models.Model):
    [...]
    something = models.BooleanField(default=False)

    [...]
    def something(self):
        return [some logic]

In that case, the function will override the setting above, making it “invisible” to makemigrations.


回答 27

您可以做的最好的事情是,删除现有数据库。就我而言,我使用的是phpMyAdmin SQL数据库,因此我手动删除了上面创建的数据库。

删除后: 我在PhpMyAdmin中创建数据库,并且不添加任何表。

再次运行以下命令:

python manage.py makemigrations

python manage.py migrate

这些命令之后:您可以看到django在数据库中自动创建了其他必要的表(大约有10个表)。

python manage.py makemigrations <app_name>

python manage.py migrate

最后:在上述命令之后,您创建的所有模型(表)都将直接导入数据库。

希望这会有所帮助。

The Best Thing You can do is, Delete the existing database. In my case, I were using phpMyAdmin SQL database, so I manually delete the created database overthere.

After Deleting: I create database in PhpMyAdmin, and doesn,t add any tables.

Again run the following Commands:

python manage.py makemigrations

python manage.py migrate

After These Commands: You can see django has automatically created other necessary tables in Database(Approx there are 10 tables).

python manage.py makemigrations <app_name>

python manage.py migrate

And Lastly: After above commands all the model(table) you have created are directly imported to the database.

Hope this will help.


回答 28

我对此错误的问题是,我包括了:

class Meta:
   abstract = True

我要为其创建的内部模型。

My problem with this error, was that I had included:

class Meta:
   abstract = True

Inside model that I wanted to creation migrate for.


回答 29

创建一个名为的新应用时,我遇到了另一个问题deals。我想在该应用中分离模型,所以我有2个名为deals.py和的模型文件dealers.py。运行时,python manage.py makemigrations我得到了:No changes detected

我继续前进,并将__init__.py其放在我的模型文件所在的同一目录(交易和经销商)中

from .deals import *
from .dealers import *

然后makemigrations命令起作用了。

原来,如果您不打算在任何地方导入模型,或者模型文件名不是 models.py不会检测到模型。

我遇到的另一个问题是我在settings.py以下位置编写应用程序的方式:

我有:

apps.deals

它应该已经包含了根项目文件夹:

cars.apps.deals

I had a different issue while creating a new app called deals. I wanted to separate the models inside that app so I had 2 model files named deals.py and dealers.py. When running python manage.py makemigrations I got: No changes detected.

I went ahead and inside the __init__.py which lives on the same directory where my model files lived (deals and dealer) I did

from .deals import *
from .dealers import *

And then the makemigrations command worked.

Turns out that if you are not importing the models anywhere OR your models file name isn’t models.py then the models wont be detected.

Another issue that happened to me is the way I wrote the app in settings.py:

I had:

apps.deals

It should’ve been including the root project folder:

cars.apps.deals