> The other would be to catch the database error and then validate
> again. But in the meantime, something else could have happened, so
> you end up with a structure like this:
>
> for i in range(settings.RETRIES)
> ... validate ...
> try:
> ... save ...
> break
> except ...
> ..
Michael Radziej wrote:
> That's a good spot.
>
> It's hard to impossible to catch the error and figure out what the
> error message means, since there's no real standard how these error
> messages look like. All you got is a string ...
>
> One way to do this is to lock the table Post before vali
Vadim Macagon:
> ...
> Let's say I have a Post model with a title field, that title must be
> unique for a given date. Here's a sequence of events that could
> potentially happen:
>
> time: t1). User A fills in a form to create a new Post, and sets the
> title to "Donkeys".
> time: t2). User B
[EMAIL PROTECTED] wrote:
> In production mode all my errors are mailed to me. So I obviously see
> what happen.
This works fine for most errors but not for IntegrityError(s) you can
recover from, in that case by the time you get the email it's already
too late to do anything about it.
Let's s
Hi Vadim,
> Am I just taking the wrong approach here or something? Considering how
> few questions I found regarding this it would appear that most people
> are either blissfully ignoring db errors or know something I don't :)
Probably. At least I never thought about wrapping save method with
tr
There have been some questions in the past about how to catch
IntegrityError(s) thrown by Model.save(), and there were two options
suggested:
1). Don't wrap Model.save() in a try/except, because the data should be
valid before saving.
I validate the data before saving, but if validation occur
6 matches
Mail list logo
