I created a project say foo. And created an app named admin. But it causes an error
django.core.exceptions.ImproperlyConfigured: Application labels aren't unique, duplicates: admin”
So I read this and made changes as mentioned there. I marked the label as foo.admin.
I don't exactly know what the label is, but maybe this is the unique name given to an app to distinguish apps with the same name in case.
So is that mean, everywhere I have to use label instead of name?
But it causes another error.
String model references must be of the form 'app_label.ModelName'.
So I used the name in models as foo.admin in ForeignKey parameter. But the same error comes up. But the error persists.
I googled the error and found this. So I changed the ForeignKey parameter from foo.admin to admin. But in either case, I'm having this error.
So in short I want to ask
How to use apps with the same name in the same django project, like Which files are need to be modified and what to write ForeignKey parameters etc.?
(I'm using django 2.0)
Related
When building a Django application, is it dangerous from a framework or namespace perspective to create a Python class that has the same name as one of your Django models? My application uses a Python class called "Photo" to store temporary information about photos when my application is uploading them. But after I process a photo, I want to store other permanent information about the photo to my database via a Photo model. I know there's potential confusion from a programmer perspective. But aside from that risk, if the class and model are in separate modules, am I likely to run into problems or encounter strange errors because Django gets confused as to which is which?
Thanks.
I don't have an explicit reference to this fact, but you'll be fine. Keep in mind you still must follow the rules of Python, so you can't go importing name conflicts and such, but the models you are creating are themselves are subclasses of a class provided by Django, so it's not like internal functions of isinstance() would behave foolishly purely because of a similar name. When models are loaded by Django, they are indeed namespaced by app (as you can see in accessing a model in a different app, when dealing with database routers or by how the database tables are named. To get deeper, check out the source for apps.registry that ensures even model names between modules do not conflict, and apps.config for the object that deals with importing names wrapped up in a module. All this registration and app loading is going to be completed before you even get into running a lot of your Django code (assuming you didn't inject it in the way of course). Also, I have done it, so no worries about Django being too foolish when it comes to class/model names.
I have migrated my OpenERP 7.0 DB from dev to production and now everytime I try to create a new customder, I get this error:
View error Can't find field 'blocked' in the following view parts composing the view of object model 'res.partner':
res.partner.followup.form.inherit Either you wrongly customized this
view, or some modules bringing those views are not compatible*
Any idea of why I see this error?
I am a magento guy so have no clue whatsoever.
If you have frontend or backend instances. Make sure that:
All code match in both instances
Update your module
check if column exist in your table
I'm trying to deal with a very puzzling error in a Django app. When DEBUG=False, trying to delete a user (via user.delete()) gives this database error:
DatabaseError: relation "social_auth_usersocialauth" does not exist
LINE 1: ...", "social_auth_usersocialauth"."extra_data" FROM "social_au...
However, I do not have social_auth or anything by a similar name in INSTALLED_APPS, nor are there any such tables in my database, nor does any of my code reference anything of the sort (I ran a text search on 'social' in the entire project folder) - and again, this works fine when DEBUG=True. social_auth is installed on my system and on my PYTHONPATH, but I cannot see where this app is getting the idea it should be having social_auth's tables in its database, let alone why it only thinks so when DEBUG=False.
What possible pathways could my app be getting this table from and how could I convince it it's not supposed to be there?
The problem could be caused by saved generic relations realized by Django content types. Relations in Django are not only static, implemented by models and INSTALLED_APPS but also dynamic implemented by table django_content_type that saves mapping from a numeric id to app_label + model. An example of possible dynamic relationship is a permission or a comment. You can have or have not a permission to any table of any installed application. You can write a comment to everything e.g to an article, to a user to a comment itself without changing any model. This relation is realized by saving numeric id of ContentType related to that model (table) and a primary key of related object (row).
Django does not expect that someone can manipulate the database manually. If you use south for manipulation then if you after uninstalling an application then run syncdb, you are asked by south if you want automatically remove orphant content types. Then can be unused tables removed securely without beeing later referenced.
(Possible hack: delete from django_content_type where app_label='social_auth' but south is unfallible.)
Many parts of the question are still open.
Edit:
Why it was not the right way: All generic relations are from descendants to the parent and all data about the relation are saved in descendant. If the child app is removed from INSTALLED_APPS then django.db code can nevermore try to remove descendants because it can not recognize which columns contain the relation data.
This table is created by django-social-auth application.
Looks like you've added it to your project and haven't launched migrate (or syncdb).
I have a app called C3po. I'm working on the model "Article". In this model I want to create a ForeignKey field with a custom related_name to a model in another app called Lea. To make sure the related_name is unique, I want to name it "c3po_articles". But I don't want to hard code the app name c3po. How can I get the folder / app name in a dynamic way ? Do I use __file__ and split it or is there a more elegant method ?
Thank you for your help :)
The related_name attribute supports automatic string interpolation with two variables: app_label and class. For example:
models.ForeignKey(FooModel, related_name='%(app_label)s_%(class)s_foo')
Now, I'm honestly not sure if Django will let you just include one or the other, i.e. just '%(app_label)s_foo', but you can try. (After a closer look at the docs, I highly doubt it. It seems like it's both or neither, but still, test it yourself and see.)
See: https://docs.djangoproject.com/en/dev/topics/db/models/#be-careful-with-related-name
EDIT
Actually, after thinking about it more, for your case, you could just use '%(app_label)s_%(class)ss', which should net you c3po_articles as the related_name.
In the transition to newforms admin I'm having difficulty figuring out how specify core=False for ImageFields.
I get the following error:
TypeError: __init__() got an unexpected keyword argument 'core'
[Edit] However, by just removing the core argument I get a "This field is required." error in the admin interface on attempted submission. How does one accomplish what core=False is meant to do using newforms admin?
To get rid of "This field is required," you need to make it not required, by using blank=True (and possibly null=True as well, if it's not a CharField).
The core attribute isn't used anymore.
From Brian Rosner's Blog:
You can safely just remove any and all core arguments. They are no longer used. newforms-admin now provides a nice delete checkbox for exisiting instances in inlines.
This is simple. I started getting this problems a few revisions ago. Basically, just remove the "core=True" parameter in the ImageField in the models, and then follow the instructions here to convert to what the newforms admin uses.