On May 12, 12:47 pm, Phil Mocek
wrote:
> On Tue, May 12, 2009 at 02:25:41AM -0700, Daniel Roseman wrote:
> > No, [get_or_create is] not atomic. You can see the code in
> > django.db.models.query - it tries a db lookup, and then creates
> > a new object if one is not found.
>
> It seems that this
On Tue, 2009-05-12 at 10:47 -0700, Phil Mocek wrote:
> On Tue, May 12, 2009 at 02:25:41AM -0700, Daniel Roseman wrote:
> > No, [get_or_create is] not atomic.
By the way, that depends on what grained-ness of atomicity you're after,
which hasn't been defined in this thread. The guarantee is that af
On 5/12/2009 10:47 AM, Phil Mocek wrote:
> It seems risky to try to handle at the
> application level these things that a DBMS is specifically
> designed to do.
Well, exactly. If the correct constraints are put in place, then your
DB/adaptor would raise the proper error.
So if a row is supposed
On Tue, May 12, 2009 at 02:25:41AM -0700, Daniel Roseman wrote:
> No, [get_or_create is] not atomic. You can see the code in
> django.db.models.query - it tries a db lookup, and then creates
> a new object if one is not found.
It seems that this creates a potentially-troublesome race
condition.
On May 12, 10:04 am, Will McGugan wrote:
> Hi,
>
> I recently tracked down a strange bug in our site where 2 object existed but
> the code was expecting only one.
>
> I think this is due to get_or_create, which doesn't appear to be atomic.
> What I assume happened is that two requests came in clo
Hi,
I recently tracked down a strange bug in our site where 2 object existed but
the code was expecting only one.
I think this is due to get_or_create, which doesn't appear to be atomic.
What I assume happened is that two requests came in close together and
tested for the existence of the object
6 matches
Mail list logo
