On Sun, Feb 10, 2013 at 10:50 AM, Some Developer <someukdevelo...@gmail.com>wrote:
> On 10/02/13 15:07, Bill Freeman wrote: > >> Did you previously have a field named 'title' in this model that was >> marked unique, that you have since removed? If so, the column may still >> be in the database with a unique constraint. Since it's no longer in >> the model, some default may be being used when you save, and that's >> obviously not unique. Use suitable tools for your database (if >> PostgreSQL, I suggest PGAdminIII) to examine the schema. You may be >> able to drop the column, or at least the constraint (back up the >> database first). >> >> If there never was such a field, then the problem originates in another >> model. You still may be able to figure it out by inspecting the >> database schema. You can also temporarily set up to catch the Integrity >> Error close to the origin, and call pdb.set_trace(), where you can >> examine the query to see what models are involved. >> >> Bill >> > > OK, I've just found something rather strange. If I just do a simple: > > tag = BlogTag(title=form.cleaned_**data['title'], > > description=form.cleaned_data[**'description'], > num_articles=0) > > tag.save() > > I get an IntegrityError and the model fails to save. On the other hand if > I do the following: > > try: > tag = BlogTag(title=form.cleaned_**data['title'], > > description=form.cleaned_data[**'description'], > num_articles=0) > > tag.save() > > except Exception: > pass > > the model saves correctly (I've checked manually in the SQLite database) > and there is no error shown at all (as expected since I have ignored the > exception). > > Any idea why this is the case? If it truly were a database constraint > violation I would have assumed that it would fail to save no matter what > you did regarding Python exceptions. > > This feels like a bug in Django to me. > > Suggestions welcome. > > I have to agree that catching exceptions doesn't clear IntegrityError. But that still doesn't tell us where the bug is. Does this happen on the development server? If so, then my suggestion is to sprinkle in a pdb.set_trace() or two, poke around and/or single step over a few things, then go around again and single step into the thing that fails, and repeat until enlightened. If it only happens on a production server, you're stuck with printing stuff. For instance, since your except only has a pass, we don't actually know whether it was reached. You can't in general, print to stdout. I believe that apache/mod_wsgi puts stuff sent to stderr in the apacvhe longs. Django's logging may help. I'm fond of writing a little function that appends its text argument to a file of your choice. Bill -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
