On Jan 24, 11:41 am, Karen Tracey <kmtra...@gmail.com> wrote:
> Just a note -- what you are describing is unique URLs per-user. You
> confused me a bit with how you phrased it as duplicate URLs are allowed by
> what you have specified, so long as they are associated with different
> users.
Right. Sorry for the confusion.
> You left out the form definition. I'm guessing it's a ModelForm? Also I'm
> guessing you excluded the user from the form? Note if it is a ModelForm,
> and all the fields involved in unique_together were in fact included in it,
> then the form validation would do the unique check for you, and you wouldn't
> have to worry about the save causing a database error, assuming you could
> guarantee no other save was made that might invalidate the unique check done
> by is_valid() before the committing save() ran. But if you exclude one of
> the fields or can't guarantee a duplicate entry hasn't been inserted between
> the validation check and the committing save, then you do need to deal with
> the potential database error.
For full disclosure, here's my LinkForm:
class LinkForm(ModelForm):
class Meta:
model = Link
exclude = ('user',)
def __init__(self, request, *args, **kwargs):
super(LinkForm, self).__init__(*args, **kwargs)
self.request = request
self.fields['category'].queryset = Category.objects.filter
(user=request.user).order_by('name')
Based on what you describe above, it sounds preferable to let Django
handle the unique_together on is_valid(), but I don't think I can do
that since I need to attach the user to the form later since I don't
know it until the request comes in. So I'm stuck with having to do my
own error checking, correct?
> So...if you can't call transaction.rollback() because the code is not under
> transaction management, ensure it is under transaction management whenever
> you might need to call transaction.rollback(). Probably easiest to just
> wrap it in commit_on_success:
>
> http://docs.djangoproject.com/en/dev/topics/db/transactions/#django-d...
>
> Alternatively you could use the lower-level connection rollback routine and
> bypass the django.db.transaction layer, but I think it's cleaner to stick
> with the higher level routines.
OK. I added commit_on_success to wrap the view and am now able to
rollback on IntegrityError.
Thanks,
Rob
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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
-~----------~----~----~----~------~----~------~--~---
