On Jun 14, 1:24 am, felix <crucialfe...@gmail.com> wrote:
> brilliant, you are correct:
>
> Foreign-key constraints:
> "traffic_tracking2010_content_type_id_fkey" FOREIGN KEY
> (content_type_id) REFERENCES django_content_type(id) DEFERRABLE
> INITIALLY DEFERRED
> "traffic_tracking2010_src_content_type_id_fkey" FOREIGN KEY
> (src_content_type_id) REFERENCES django_content_type(id) DEFERRABLE
> INITIALLY DEFERRED
> "traffic_tracking2010_user_id_fkey" FOREIGN KEY (user_id)
> REFERENCES auth_user(id) DEFERRABLE INITIALLY DEFERRED
>
> I wouldn't want to change that anyway.
>
> Now what I still don't get is:
>
> # doesn't protect against foreign key errors anyway ??
> try:
> sid = transaction.savepoint()
> tracking.save()
> transaction.savepoint_commit(sid)
> except Exception,e:
> get_logger().exception("tracking save: %s (%s)" % (src,e))
> transaction.savepoint_rollback(sid)
>
> why that attempt to commit just that save doesn't raise.
>
You are creating a savepoint. Savepoint isn't a full commit, so
deferrable constraints aren't checked.
> I really don't want to have to check for existence of User and
> ContentType
You could run with raw sql the following before trying to save:
from django.db import connection
cursor = connection.cursor()
tracking.save()
cursor.execute("SET CONSTRAINTS ALL IMMEDIATE")
cursor.execute("SET CONSTRAINTS ALL DEFERRED")
>From postgresql documentation (http://www.postgresql.org/docs/8.4/
static/sql-set-constraints.html)
"When SET CONSTRAINTS changes the mode of a constraint from DEFERRED
to IMMEDIATE, the new mode takes effect retroactively: any outstanding
data modifications that would have been checked at the end of the
transaction are instead checked during the execution of the SET
CONSTRAINTS command. If any such constraint is violated, the SET
CONSTRAINTS fails (and does not change the constraint mode). Thus, SET
CONSTRAINTS can be used to force checking of constraints to occur at a
specific point in a transaction."
The risk here is that you have something else than the tracking.save()
with deferred foreign key check pending. Now, that check could fail at
the point you run SET CONSTRAINTS ALL IMMEDIATE. The risk should be
small, though. Note that I haven't tested this code...
Anssi
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
