Django 1.9 deprecation warnings app_label

后端 未结 12 621
花落未央
花落未央 2020-12-01 05:09

I\'ve just updated to Django v1.8, and testing my local setup before updating my project and I\'ve had a deprecation warning that I\'ve never seen before, nor does it make a

相关标签:
12条回答
  • 2020-12-01 05:20

    Sometimes an invalid .pyc files that doesnt match with the current source code caused this problem.

    I removed all .pyc to refresh all of them using this bash

    find . -name "*.pyc" -exec rm -rf {} \;

    0 讨论(0)
  • 2020-12-01 05:23

    The Django 1.9 way of handling this and giving your app a nice name in the admin is to do the following:

    Add a file in your app named apps.py and add the following to it:

    #apps.py
    from django.apps import AppConfig
    
    
    class YourAppNameAppConfig(AppConfig):
        name = 'yourappname'
        verbose_name = 'Your App Name Looking Right'
    

    Then, in your app's __init__.py file, add the following:

    #__init__.py    
    default_app_config = 'youappname.apps.YourAppNameAppConfig'
    
    0 讨论(0)
  • 2020-12-01 05:24

    Add a meta class to your model with an app_label attribute.

    class Meta:
        app_label = 'app_model_belongs_to'
    

    Hope this works!

    EDIT: The reason for this is usually that the model exists outside of the standard locations.

    For more information refer to: https://docs.djangoproject.com/en/1.8/ref/models/options/#app-label

    0 讨论(0)
  • 2020-12-01 05:24

    The easiest and simplest way to solve this is to place the "import signals" command at the BOTTOM of the Model file you are working with. This ensures that the models are all loaded before the signals for that model are imported. You would have to do this for each model you are importing (if you use receivers linked to particular models), or in the models.py for the app that comes at the end of the "installed apps" in your settings.

    The other solutions are only required if you are dealing with non-model type signals, where the models will never be imported first.

    Why this is not noted in the docs is a mystery, because I just got caught by it, until I remembered that you have to do that.

    models.py

    from django.db import models
    
    class MyModel(models.Model):
        myfield1 = models.CharField()
        myfield2 = models.CharField()
    
    import signals
    

    And then in signals.py:

    from django.db.models.signals import pre_save # Or whatever you are using
    from django.dispatch import receiver
    
    from .models import MyModel
    
    @receiver(pre_save, sender=MyModel)
    def my_receiver(sender, instance, **kwargs):
        mysender = sender
        print mysender
    

    Like that.

    0 讨论(0)
  • 2020-12-01 05:28

    I has this problem after upgrade Django from 1.8 to 1.9.1:

    RuntimeError at /

    Model class blog.models.BlogCategory doesn't declare an explicit app_label and isn't in an application in INSTALLED_APPS.

    This help to resolve:

    in blog/models.py:

    class BlogCategory(models.Model):
        some vars & methods
    
        class Meta:
            app_label = 'BlogCategory'
    

    It's work on 100%.

    0 讨论(0)
  • 2020-12-01 05:28

    I had the same problem. I put a breakpoint in django.db.models.base.py:line82 and try to figure out what is causing this warning message.

    # Look for an application configuration to attach the model to.
    app_config = apps.get_containing_app_config(module)
    

    Basically, if your app does not exist by this time, you get that warning. I realized that my problem was that I have a third party framework (in my case, haystack) that tries to import one of my custom models.

    Maybe you also have a third party package listed in INSTALLED_APPS before your custom apps and your third party package references your custom apps? This would be possible if you are using something like Django rest framework as well.

    0 讨论(0)
提交回复
热议问题