On the web page, I get the following error:
FieldError at /foo/bar/
Cannot resolve keyword 'foos' into field. Choices are: __unused__, [snip]
The problem code is
User.objects.filter(foos__name='bar')
When I run this in the shell, it works and I get a recordset:
>>> User.objects.filter(foos__name='bar')
[<User: JordanReiter>]
But on the webpage I get the exception above.
I've never run into this issue before and I wonder if I'm missing something?
Update
Based on doing a diff between the "Choices are: ..." on the web and in the shell it appears there are 7 fields that are available in the shell that aren't available if I do the query on the web. They appear to be ordinary ForeignKey fields pointing to User, with no difference from the other fields that work.
Tested So Far
INSTALLED_APPS are identical for both settings
runserver version also works (as would be expected)
User used is identical in both cases and is django.contrib.auth.models.User
related names for the shell's User and the web app's User are definitely different. User._meta.get_all_related_objects() in the shell displays around 7 more related fields than the if I dump that from the web app.
values for settings are also basically identical (one has the TEST_XYZ settings but those don't affect anything)
This is only sort-of an answer. Turns out the reason that the field is not available is because all of the installed apps' models do not correctly load in when the app is first compiled, so the app permanently believes certain fields don't exist, even after they recognize the models for those fields do exist. It appears to be related to this earlier, equally confusing problem:
SO: Internal Server error on the first request (and only the first request) after server reload
Oh, and so how I fixed it was to change areas of code that imported the models that the web server couldn't find on the first request. Somehow, omitting those meant that the server would recognize that the fields in question were present. Super weirdness!
Reverse foreign keys are only added to models if the app they are in is in INSTALLED_APPS. I know you say that your settings.py is the same as in development, but somehow it is the case that your foo app is in INSTALLED_APPS locally, but not on the server. Do you have a local_settings override perhaps?
Related
I've installed multiselectfield on my machine and it works well. I can choose multiple items thanks to multiple checkboxes in admin:
Then I had to copy/paste all the files of the project to my VPS using Filezilla. So I have the exact same code and the exact same files locally and remotely. The site works well remotely (the VPS django admin page too).
However on the server's django admin page, the multiselectfield widget shows a simple text field instead of an actual list of checkboxes, plus it says Enter a list of values. when I try to validate the form.
So, how is it, that with the same code at two different places, the multiselectfield acts differently and how to I fix this ?
my field looks like this in the model:
ram_list = tuple((ram.ref, ram.name) for ram in RAM.objects.all())
ram = MultiSelectField(choices=ram_list)
I have a strange issue I've never seen before and I'm a bit stuck at where to go next.
We have a fairly standard Django app, with some forms using class based views, and we're finding that state is getting mixed between forms in strange ways.
For example, User A is on the site and fills out form X and sets their postcode.
User B goes to another form altogether, form Y, but the postcode field is already populated with User A's postcode.
The fields share the same name, but are on totally independent forms. The field in this example is a standard Django CharField.
I haven't managed to replicate this behaviour using the Django dev server locally from a little trying. I've upgraded gunicorn to latest version, I've set it to use a single worker, I've disabled caching everywhere in the Django project that I can find.
It's stuck on Django 1.3.7, and it's not a trivial app to upgrade to a supported version. It's running with gunicorn 18 behind nginx.
I've noted the Django mentions of thread safety in class based views, but I don't see us passing any mutable objects to the view, and it's all a fairly plan view and ModelForm. Django's session store is the default (it was previously something else but I removed that to use the Django default which I believe is the db).
Any ideas where to go next to try and figure this out?
Thanks!
Figured it out - turns out it was to do with the behaviour of get_initial in 1.3, which was changed in Django 1.4
https://docs.djangoproject.com/en/dev/releases/1.4/#formmixin-get-initial-returns-an-instance-specific-dictionary
We changed our get_initial to use a copy of the dict rather than the default implementation, and now all is well :)
I'm getting this weird AttributeError on the app I'm currently working on. I'm developing using the development web server i.e. "runserver" command of django toolsets. Then I decided to test the application on apache+mod-wsgi and I persistently get this error though it works fine sometimes. So I think there must be something wrong with that piece of code,
so I decided to comment it out and see what happens. And YES, it still give me the same error (See 2nd picture). <-- NOT RELEVANT NOW. The AttributeError I'm getting on custom User model, even if it actually contains the classmethod get_by_type_and_id() is what I'm interested on.
Have you even seen like this one before? What do you think is causing this? I've followed the tutorial here to deploy it. Note though that User is not the built-in django User model. I think it's a "customized,stripped-down" implementation based from the django's Auth module.
Note that I have not gotten this error on my development using django's own development server. This only happens when I deployed the app on Apache+mod_wsgi.
More Info:
Django version == 1.2.5
Thanks! I'd really appreciate any kind of help.
First Picture:
2nd Picture:
Few things to notice:
Are you sure that you have get_by_type_and_id method for the User?
You set pasword instead of password (typo)
I think you have to indent line 60 in your second screenshot
After hours of diving into the code, I had a eureka moment. So I thought, maybe at some point django.contrib.auth.models.User model is being put into action by some django module used in the application. Because like I mentioned, this app's User model is customized and the application is not using django.contrib.auth.* at least directly. This was my suspicion because this kind of error is not specific to that particular attribute. Sometimes it gets through that point, but then another AttributeError would occur on some other view referring to other User model attributes. Then at one point I noticed that the attributes of User in the error messages was that of django.contrib.auth.models.User.
So I decided to "remove" django.contrib.auth.models on my python path, and there it showed, an error occurred in one of the modules I'm using specifically django.contrib.messages. I removed it, and I'm not seeing the AttributeError again. It turned out that django's Message model has a foreign_key to django.contrib.auth.models.User.
But then, I lost the flexibility of django message framework, especially when I'm using it on view with a HttpResponseRedirect i.e. no way to put useful messages in a template's context. or maybe there is? :)
UPDATE 2 (Pretty Sure Now):
Yes, I'm pretty sure now that django.contrib.messages is the one causing the error. I tried reproducing the error on another application which uses the customized User model i.e. not django.contrib.auth.models.User. I enabled django.contrib.messages module and produced basically the same error. I would like to know why is this happening on Apache+mod_wsgi, but not on django's own development server.
I just delayed my first Django app via Heroku and I'm having an issue that's proving very difficult to resolve. I have django-registration and profiles installed and apparently something runs afoul unless the 'django.contrib.sites', and SITE_ID is removed from settings. Unfortunately, when content is submitted by a user to be displayed, I'm getting the following error:
TemplateSyntaxError at /Caught AttributeError while rendering: 'Settings' object has no attribute 'SITE_ID'.
Only when deleting the user submitted content via the admin does the site reestore.
Adding django.contrib.sites and SITE_ID back just kills the whole app. These issues did not arise during initial development, but only began when the app was deployed. Looking to see if anyone has any insight or advice on how to resolve this.
What kind of error do you get when you add SITE_ID in the settings file?
This problem usually occurs when there is a discrepancy with data in the table django_site. Check if your dev and prod database have the same values in that table. Some models may refer to some Django models that use the Site models itself, and unless they cannot find a valid django.contrib.sites.models.site instance in the database, they will raise an exception. This happens if using the FlatPage models for instance.
Trying to get an oauth module to work I made the pro-move of : manage.py reset sites
This had the effect killing the admin and login functionality of my site.
So, my question is how to I get back to square one and fix what I broke.
Here is my current error when trying to display the admin tool:
DoesNotExist at /admin/
Site matching query does not exist.
Request Method: GET
Request URL: http://mdev.5buckchuck.com/admin/
Django Version: 1.3
Exception Type: DoesNotExist
Exception Value:
Site matching query does not exist.`
I looked at the documentation but I am lost and tired in it:
http://docs.djangoproject.com/en/1.3/ref/contrib/sites/
It seemed to indicate: manage.py syncdb
So, I wonder what to do next...
You don't really need the sites framework if you only run one site from the project, so the easiest fix would be to remove the following item from your INSTALLED_APPS and the error should go away:
'django.contrib.sites'
You can also re-create the missing Site object from shell. Run python manage.py shell and then:
from django.contrib.sites.models import Site
Site.objects.create(pk=1, domain='mdev.5buckchuck.com', name='5buckchuck.com')
Provide SITE_ID=1 in settings.py. This will work.
I went through this problem too, while playing with django-allauth. The application offers the ability to delete sites. If you delete the one designated by the SITE_ID parameter in settings.py, you'll have to point the correct PK of another valid site.
If you deleted the default site example.com(changes are you did some cleanup after adding another site), you may simply want to select the other site you created by setting SITE_ID to 2 for example. If you work with SQL database, look for the django_site table, and locate the site ID you wish to work with.
This way, no need to go into shell and recreating a not necessary desired site.
If you need sites, you can use data fixtures. Read the docs for tip about enabling the sites framework.