Develop Reference

Django can't delete user from my database

I have a problem with my Django project. I need to delete 1 or more users from my database but I can't do it because it returns this error:
__str__ returned non-string (type tuple)
I tried deleting it from my views but it didn't work. Than I went and used admin panel to try to delete it but the same problem happened.
If someone could give some advice or suggestion that would be great.
Thank you.

I found out what was the problem. I was returning tuple in my models __str__ function instead of a string which worked while users existed but it for some reason didn't when I tried to delete or as I later found out create a new user.

Django form error handling architecture

In the clean method of my form class I am working with many different inputs from the billing, contact, and account sections of the form. As such there are many self.add_error statements and many fields that depend on other fields in order to validate.
I have noticed that after adding an error for a field I am unable to access that field any more. This is strange as you can add more than one error to a field, but that is not the issue.
I am seeing this method grow more complicated and unreadable, is there a good way to do this so the person that comes after me will understand it? I don't feel that the code ordering to prevent access after error is appropriate. My only thought is to set error variables in clean and call a different method at the end to add the errors to the fields.
Thanks
Edit: To add, I am only returning after clean has run in order to give the user all errors at once. I did not feel that returning after each found error was a good user experience

It's good practice to provide your code to help people see what you are doing. This includes your error reports/traceback info. Use the markdown options to help make your post more readable.
I could be wrong but from my own experience, I usually clean each field individually as per the documentation unless they rely on each other such as passwords, etc.
you can read this part of the documentation to help get some clarity:
https://docs.djangoproject.com/en/1.10/ref/forms/validation/#cleaning-a-specific-field-attribute

Getting ImageField file path post_delete

I'm making a little piece of software with Django and JS that will handle image uploads. So far, so good. I'm getting nice little images via AJAX from dropzone.js. They are saved on the file system and have an ImageField in my Photo model to keep track of what is stored and where.
I even stabbed dropzone.js to nicely ask my dev server to delete the database entries and the files themselves. I find that the latter part is lacking a bit. So I started writing a function that catches a post_delete signal from my Photo model and has the task of handling the deletion from the file system. The problem is, I can't seem to find a way to get my hands on the file path that's stored in database.
If I've understood correctly, the following should work:
from django.db import models
from django.db.models.signals import post_delete
from django.dispatch import receiver
class Photo(models.Model):
imageFile = models.ImageField(upload_to=generateImageFileNameAndPath)
#receiver(post_delete, sender=Photo)
def cleanupImageFiles(sender, **kwargs):
print("Cleanup called")
p = kwargs['instance']
path = p.imageFile.name
print(path)
But when I try to output path to the console, there's nothing.
Sorry about the upperCasing instead of using under_scores as seems to be Python convention. I personally find the underscore convention a bit annoying and am having a wrestling match inside my head over whether to follow the convention or just go my own way. For now, I've done the latter.
edit: I can't seem to make it work with p.imageFile.url either as suggested here.
editedit: I also tried with pre_delete signal thinking that maybe post_delete the data has already been blown to smithereens, which would be dumb, but who knows :)
edit3: calling imageFile.path, doesn't cut it either. It just produces
[27/Nov/2016 22:29:08] "POST /correcturl/upload/ HTTP/1.1" 200
Cleanup called
[27/Nov/2016 22:29:15] "DELETE /correcturl/upload/ HTTP/1.1" 500 37
on the console window. The HTTP error 500 just comes from the view not being able to handle the delete call because of this code not working properly. That's what I use as status message to the frontend at this point.
It might be worth noting, that if I do
print(p)
the output on the console is
Photo object

If you need the path of the image, try:
path = p.imageField.path
P.S.: Yes, you should follow the convention. Otherwise it will be hard for others to read your code if you share it with somebody, or contribute to an open source project, or hire programmers in your company, etc.

I knew I had to have done some stupid and finally had time to get back to debugging.
In my view I'd done
deletable = Photo(id=id)
instead of
deletable = Photo.objects.get(id=id)
thus ending up with a new photo object with just the id field filled in. Because Photo.save() was never called this didn't end up in my DB and no errors were thrown. Because of this, the bug flew stealthily under my radar.
Thus, when finally calling
deletable.delete()
it only removed the uncomplete instance I had just created. Although, it also deleted the proper entry from the DB. This is what threw me off and made me mostly look elsewhere for the problem thinking I had the correct database object in my hands.
Where this behavior came from remains unclear to me. Does delete() actually check the database for the id (which it in this case would've found) instead of just handling the instance in question? I guess taking a look at django.db.models.Model.delete() could shed some light on this.

In upgrading to Django 1.8, why do I get the AttributeError 'ManyToManyRel' object has no attribute 'rel'?

I'm going through and checking the various pages in our project, and the great majority appear to be working fine after the upgrade. However, when I try to view a particular entry in the admin, I get this error. On viewing the stack trace, everything is being done internally within Django's admin code, so there is no place in my own code that I can go to debug. This would suggest either that there is something wrong with the Django admin or that there is some release note I missed that is necessary to make this work properly. Any ideas? The actual error is happening here:
site-packages/django/contrib/admin/helpers.py in contents, line 206
if isinstance(f.rel, ManyToManyRel) and value is not None:
result_repr = ", ".join(map(six.text_type, value.all()))
else:
result_repr = display_for_field(value, f)
Obviously, I could go into Django and hack around, but I shouldn't have to do this on a new installation. Any help on pinpointing the issue would be much appreciated. I'm just staring t the screen at this point.

Was responding to Alasdair's comment and got to playing with our admin code, and I was able to narrow it down to the method call that was causing the error.
We have a Lead model that relates to our Company model via a ManyToManyField (i.e. one lead can be for one or more companies). The field that relates Lead to Company has a related_name of "leads".
class Company(models.Model):
...
class Lead(models.Model):
companies = models.ManyToManyField(Company, blank=True, related_name='leads')
...
The CompanyAdmin, looks like the following:
class CompanyAdmin(admin.ModelAdmin):
...
readonly_fields = 'leads',
...
def leads(self, obj):
...
So what appears to have been happening was, when we were trying to access the leads method from CompanyAdmin, Django was instead trying to access the company's Lead objects via the related name -- the ManyToManyField that was throwing the error. I resolved the conflict by changing the method name in the admin to "my_leads".
Looks like something was changed somewhere between 1.8 and the final version of 1.6 that has opened the door to potential conflict between related names and admin methods. The solution, make sure there is no overlap in naming, and things should work fine.

Issue with lazy translation and Basic Blog in Django

I've been using the blog that comes with the Django Basic Apps for quite some time now, and haven't had any problems until now. The error I have been getting happens any time I try to access the single page for a newly created blog post. Note that this is only happening for recently created posts; earlier posts work just fine.
This is the only thing Django tells me:
No <django.utils.functional.__proxy__ object at 0x105ab8890> found for
I've done a bit more research and determined that Django has some sort of a lazy translation functionality, and that is the object that is not being found. I'm still completely confused as to what parameter I could have changed that would suddenly cause this issue.

Have you added some _() translated strings recently? Could you post the code, or an example of which creates this error?