I created following custom user model by using "AbstractUser" model.
from django.conf.global_settings import AUTH_USER_MODEL
MyCustomUser(AbstractUser):
regions = models.ManyToManyField(to='SomeModel')
class Meta:
app_label = 'myapp'
MyObject(models.Model):
owner = models.ForeignKey(to=AUTH_USER_MODEL)
And I set AUTH_USER_MODEL to settings/base.py (I separated setting file each environment. e.x: settings/base.py, settings/development.py).
AUTH_USER_MODEL = 'myapp.MyCustomUser'
When I executed python manage.py syncdb, my console window has flared up by Django!
myapp.MyObject: 'owner' defines a relation with the model 'auth.User', which has been swapped out. Update the relation to point at settings.AUTH_USER_MODEL.
So, I had two questions.
Is the problem is that I separated settings.py each environment.
Does from django.global_settings import AUTH_USER_MODEL import myproject.settings?
And I resolved from myproject.settings.base import AUTH_USER_MODEL in this time.
global_settings is, as the name implies, the global default settings supplied by Django. So of course the default is 'auth.User'.
Since you override it in your own settings, you should import that instead. But as the documentation says, the way to import the current settings is always from django.conf import settings, rather than explicitly importing a settings file in your project.
Also note though that rather than using the settings at all here - which could lead to some dependency issues on startup - you should be using get_user_model() from django.contrib.auth, as explained in the documentation.
Related
after customizing django oscar app (address) and adding a new field named 'area' when I run migrate it gave me Unknown field(s) (area) specified for UserAddress
I used the command
./manage.py oscar_fork_app address myappsfolder/
after creating the folder and __init__.py file in it
then I started to customize the app like this:
#myappsfolder/address/models.py
from django.db import models
from django.conf import settings
from django.utils.translation import ugettext_lazy as _
from oscar.apps.address.abstract_models import AbstractAddress
class Address(AbstractAddress):
area = models.CharField(_("Area"), max_length=120,
choices=settings.AREA_CHOICES, blank=True)
from oscar.apps.address.models import *
#myappsfolder/address/forms.py
from oscar.apps.address import forms as base_forms
class UserAddressForm(base_forms.UserAddressForm):
class Meta(base_forms.UserAddressForm.Meta):
fields = ['area']
I didn't touch the admin.py , config.py and __init__.py that have been created by the command ./manage.py oscar_fork_app address myappsfolder/
also the __init__.py that I created in myappsfolder is empty, should I add something to these files ?
What should I do to customize this app ? or any other app ?
If I edited the models in oscar/apps/address/abstract_models.py it only apply in local host and the error in forms disappear , which means that django still reading the models from oscar/apps not from myappsfolder.
You cannot override AbstractAddress in that way because the changes will not propagate to other models such as UserAddress that directly subclass AbstractAddress. Instead you need to override the specific address models that you want to change. So if you want to change UserAddress then override that particular model:
from oscar.apps.address.abstract_models import AbstractUserAddress
class UserAddress(AbstractUserAddress):
area = models.CharField(_("Area"), max_length=120, choices=settings.AREA_CHOICES, blank=True)
... after which your changes to UserAddressForm should work.
If you need to override ShippingAddress as well, then you will also have to fork the shipping app and do the same thing there, because that is where the model lives.
I am using oscarcommerce for my django project. I want to extend the "StockRecord" model to include some more fields. So I forked the partner app as follows. (boscar is my app name)
python manage.py oscar_fork_app partner boscar/
It successfully forked and new files were added to boscar/partner folder. I added 'boscar.partner' in my installed apps.
Now I added new fields in StockRecord models as follows
boscar/partner/models.py
from django.db import models
from oscar.apps.partner.abstract_models import AbstractStockRecord
class StockRecord(AbstractStockRecord):
effective_price = models.FloatField(default=0, null=True)
is_instock_item = models.BooleanField(default=False, null=True)
instock_quantity = models.IntegerField()
from oscar.apps.partner.models import * # noqa
Now when I try to make migrations it shows the following error.
RuntimeError: Conflicting 'stockrecord' models in application 'partner': <class 'oscar.apps.partner.models.StockRecord'> and <class 'boscar.partner.models.StockRecord'>.
I already successfully forked the catalogue and order models and that are working fine. Only this "StockRecord" models showing this error.
That error can occur as a result of a circular import issue associated with Oscar's support for overriding models and classes.
You need to check for places where you're importing directly from oscar.apps.partner.models. These should be replaced by importing from boscar.partner.models or using oscar.core.loading.get_model.
This question has been asked earlier: What is the purpose of apps.py in Django 1.9?
Application configuration objects store metadata for an application. Some attributes can be configured in AppConfig subclasses. Others are set by Django and read-only.
However, what does it mean by metadata for application? Is it limited only to those AppConfig metadata:name, verbose_name, path, label, module, models_module?
Or does it make sense to extends beyonds the predefined metadata, especially for Application Specific metadata, for example in blog apps we have a date format configuration, usually defined as follows:
# File: settings.py
BLOG = {
'DATE_FORMAT': 'ddMMYYY',
}
At which it is being used as follow:
# File: blog/<...>.py
from django.conf import settings
date_format = settings.BLOG['DATE_FORMAT']
On contrary, we could move this configuration into blog/apps.py as BlogConfig?
class BlogConfig(AppConfig):
name = 'blog'
verbose_name = 'Awesome Blog'
date_format = 'ddMMYYYY'
So that throughout the code in the application, date_format is being used by:
# File: blog/<...>.py
from django.apps import apps
date_format = apps.get_app_config('blog').date_format
It sounds to me that settings.py is project settings, but not an application settings. Thus it is more sounds to put all application settings inside apps.py then settings.py. So, is this a valid assumption/argument/convention for me to put application configuration inside apps.py instead of settings.py?
A project is unique per django installation, while an app is supposed to be reusable.
If you put custom app settings in your project's settings.py they are supposed to be modifiable, especially if you (or others) reuse this app for another project.
Now, if you put these custom settings in your app's apps.py, this means they won't be modifiable on a per project basis. In which case there is no reason to put them in apps.py rather than in a constants submodule for instance. Unless you want to provide a limited set of possible configs:
class BlogConfig(AppConfig):
name = 'blog'
verbose_name = "Blog"
date_format = 'ddMMYYYY'
class CustomizableDateFormatBlogConfig(BlogConfig):
date_format = getattr(settings, 'BLOG_DATE_FORMAT', BlogConfig.date_format)
class I18nBlogConfig(BlogConfig)
verbose_name = _("Blog")
The default_app_config would be BlogConfig but the project using the app would be able to choose CustomizableDateFormatBlogConfig or I18nBlogConfig as well.
However this makes very poorly customizable apps. In the example above, if you want to let the app users use both CustomizableDateFormatBlogConfig and I18nBlogConfig, you would need to do something like this:
class BlogConfig(AppConfig):
name = 'blog'
verbose_name = "Blog"
date_format = 'ddMMYYYY'
class CustomizableDateFormatMixin:
date_format = getattr(settings, 'BLOG_DATE_FORMAT', BlogConfig.date_format)
class I18nMixin:
verbose_name = _("Blog")
class CustomizableDateFormatBlogConfig(CustomizableDateFormatMixin, BlogConfig):
pass
class I18nBlogConfig(I18nMixin, BlogConfig):
pass
class I18nCustomizableDateFormatBlogConfig(I18nMixin, CustomizableDateFormatMixin, BlogConfig):
pass
So, apart specific cases where you need to provide a set of few different app configs, you'd better put your custom app settings in the project's settings.py.
This is my code in my signals.py
from .models import Entry
#receiver(pre_save, sender=Entry)
def do_stuff(sender, instance, *args, **kwargs):
pass
Now this questions is related
Django 1.9 deprecation warnings app_label
But I am not able to figure out why I need to create extra class for that.
Warning:
Model class app.models.Entry doesn't declare an explicit app_label and either isn't in
an application in INSTALLED_APPS or else was imported before its application was loaded.
This will no longer be supported in Django 1.9.
If I just empty my signals file then there is no warning.
The issue is using .models in signals as mentioned in that question
This is mostly likely because your application is not in the INSTALLED_APPS within your settings.py
I also got this error, what I found the error is in model import before it exist.
I used this to import model and it works for me
from django.apps import apps
model_obj = apps.get_model('app_name', 'model_name')
model_obj.objects.get() ...etc
I use mongoengine with django. I have two applications with models.
app1/models.py:
from mongoengine import fields
from mongoengine.document import Document
class Model1(Document):
name = fields.StringField()
lists = fields.ListField(fields.ReferenceField("Model2", dbref=False))
app2/models.py:
from mongoengine import fields
from mongoengine.document import Document
class Model2(Document):
name = fields.StringField()
All applications were added to INSTALLED_APPS. When I use the django dev-server, everything is fine. But using this code with uwsgi-server there is an error:
Model2 has not been registered in the document registry.
Importing the document class automatically registers it, has it
been imported?
What I should do?
You should import app2.models somewhere. Put a comment by the import saying why it's there, so nobody removes the useless-looking import in the future.
When the django dev server starts up it imports the models from all installed apps and validates them. You'll see
Validating models...
0 errors found
This does not happen in a production environment. It is just a nicety of the dev server.