On 11/02/13 14:54, Bill Freeman wrote:
On Sun, Feb 10, 2013 at 10:50 AM, Some Developer
<someukdevelo...@gmail.com <mailto: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
Apologies for the late response I've had a somewhat busy week with work.
Problem solved. It was a bug in Django Debug Toolbar. Disabling the
following panel fixed the issue completely.
'debug_toolbar.panels.profiling.ProfilingDebugPanel',
I'm glad that particular problem is sorted :).
--
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.
