Improved Error Reporting in Django - GSoC

[Sachin Gupta]

Hi,

My name is Sachin Gupta and I am student of Indian Institute of Technology 
Roorkee, in my final year of undergraduate course in Computer Science. I 
have been developing a project entirely based on Django for the last 4 
months. Here is the link <http://www.mycareerstack.com/> and it has been 
absolutely fun using Django. But I have had my share of trouble with the 
error reporting so I wanted to contribute to improve it. In some of the 
cases the error reports came up were so unrelated it took me some time to 
eventually figure it out. 
 
I would like to list a few of them here:

1) One of the very basic one is that in some cases where we may have an 
indentation error, it is not reported which file has that error. It just 
throws 

indentation error in views.py 

 For a new developer it may appear that the error is in the views.py file 
in the root directory(if one such exists) but the error may actually be in 
any of the views.py file of the apps.
 
2) Another error that bugged me for a long time was related with 
comment_was_posted signal. I made a mistake in the listener function for 
the comment_was_posted signal So whenever I posted a comment, I got the 
error

IntegrityError at /comments/post/

The integrity error was at the listener of the signal, but the url does not 
depict that.

3) Another point (it may be intentional) is that if some attribute is 
missing in the Queryset or the attribute name is wrongly written (in the 
then  template) a TemplateError is not raised. It just fails silently. 
Personally, I feel that it should throw some error, otherwise it can lead 
to some bugs that might be difficult to discover.

These are some of the errors that, if reported would have made things 
easier for me. Although I have used django extensively, I am not quite 
familiar with the error reporting facility. I have forked the git 
repository on github and will go through it in the next few days. 

Since this is also listed as a topic for GSoC 2012, I am interested in 
applying for that. Meanwhile it would be great if I can be suggested some 
pointers. 

Cheers

Sachin Gupta

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/DGqEVIAVOb0J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Improved Error Reporting in Django - GSoC

[Sachin Gupta]

Hi Andrew

As about the silent template failure I was not very sure if it was a 
deliberate design decision, but since it a deliberate design decision I 
would not like to change it. Since I did both the backend and template 
editing, it appeared to me that some error should have come.

But I would like to make the error reporting from signals a little better. 
What I would like to do is to trace the control flow and throw the error 
according to the context of the flow. About how I plan to do that, I need 
to go through the code base thoroughly and will try to come up with a 
method.

I went through the https://code.djangoproject.com/wiki/BetterErrorMessages
 page. 

Today I will go into the following errors 

Some of the django.db errors and also at 
Ticket:#15126, 
when a user forgets a trailing comma in a single-item tuple then the error 
message is quite misleading.

Could you guide me what number of error fixes would be good work for GSOC 
proposal. Also if there are any class of Django errors that are of greater 
concern (like django.db)

Regards
Sachin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/cuYearvU_OoJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: auth.User refactor: reboot

[Sachin Gupta]

Hi 

I have just been using Django for the last 4 months, and the application I 
developed needed an extensive UserProfile module. It needed things such as 

   1. Ability to log in via both email and username
   2. Ability to link multiple social accounts with the same user account 
   (the social connections were primarily used for logging in, but they can be 
   extended to store and use the social account information)
   3. Ability to link multiple emails with the same account and having one 
   email as the primary verified one

These were some of the features that I needed. After a bit of looking 
around I resorted to using 
django-allauthfor the registration 
part(also manages social connections) and made a 
custom UserProfile model. The result of this was that auth.user just 
reduced to a FK (I also didn't have much need of the permissions). 

Just to give a new user's perspective I would say, pluggable auth.user does 
not seem to be the correct way to go. A much better approach would be to 
BaseClass the auth.user and allow developers to subclass user model 
according to their needs. To maintain backward compatibility the existing 
fields need to be maintained. This does not solve the problem of smaller 
email field size, but then a lot of things would break.

The problems of increasing email field length and maybe combining first and 
last name field to a single field can be solved incrementally.

Regards
Sachin 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/6mqH-9GnkqQJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Improved Error Reporting in Django - GSoC

[Sachin Gupta]

Hi Andrew

I am going through the errors on this page 
https://code.djangoproject.com/wiki/BetterErrorMessages particularly the 
django.db errors. The error which is listed on the page might not be updated

For the error message

OperationalError: Unable to close due to unfinalised statements

The context is not correct. I tried using a file that does not have write 
permission for sqlite3, but the error that came up is not what is listed 
above. The error message was quite appropriate in this case

django.db.utils.DatabaseError: attempt to write a readonly database

So is there something which I am not getting correctly?

Regards
Sachin



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/p66JQSKUDkMJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

How to generate an edit form for django comments

[Sachin Gupta]

Hi, 

I wanted to have a functionality to be able to edit the comments posted 
using the comments app (not from the admin, from the site and only for 
logged in users). As much as I know Django, to render an edit form we need 
to pass an instance of the object to the form which has to be edited like

form = SomeForm(instance=some_object)

But when I try to do the same in case of CommentForm imported from 
django.contrib.comments.forms, I get an error  __init__() got an unexpected 
keyword argument 'instance'.
When I check the comment form I find that the __init__() for the comment 
form is overwritten and it does not accept the `instance` argument. If the 
form cannot accept this argument, it means I cannot generate an edit form.

Is there any work around?

Thanks,
Sachin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/4aX7tZVf6mkJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.