Hi,
I'm using rev 7713 (I need to port to the new upload handling before I
can get back to trunk).
The code that actually adds to the table:
def do_update(self, event):
if event.countable:
matrix, new = self.get_or_create(date=event.time.date(),
memb
What version are you running, and what's the exact line you're using
for get_or_create?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers
I'm experiencing the issue with concurrent writes on a low traffic
site hosted on a single machine DB and web server. I'm logging
reporting events in certain views and everytime I get indexed by a
search engine, this error floods into my inbox.
If I implement the workaround of hiding the multiple
Travis Terry wrote:
> It's my understanding that SELECT ... FOR UPDATE only locks the rows
> that it reads (so you can be sure they can be updated or referenced
> later in the same trasaction). However, in the case of get_or_create(),
> there is no existing row
Oh... Indeed. Then this won't h
Ivan Sagalaev wrote:
>
> Actually there is a common solution to this problem that doesn't create
> duplicates and doesn't fail on second transaction. And as James
> correctly has noted it works on database level. The solution is a form
> of SELECT called SELECT FOR UPDATE. When one transaction
Travis Terry wrote:
> 4. P2's get_or_create() tries to create the item. One of two things
> happens:
> a. a second item is created with the same parameters if this doesn't
> violate a UNIQUE constraint
> b. the second create fails (because of a UNIQUE constraint) and
> raises an except
On Dec 4, 2007 2:21 PM, Travis Terry <[EMAIL PROTECTED]> wrote:
> exception escape, then everywhere I call get_or_create() will have to
> implement a very non-DRY piece of identical code to handle the situation.
I won't get into the issue of whether this should or shouldn't be in
core, but you mo
On Dec 4, 2007 11:21 AM, Travis Terry <[EMAIL PROTECTED]> wrote:
> Otherwise, if it lets the exception escape, then everywhere I call
> get_or_create() will have to implement a very non-DRY piece of identical
> code to handle the situation.
>
> Travis
>
Couldn't you implement your own DRY soluti
On Dec 4, 2007 4:21 PM, Travis Terry <[EMAIL PROTECTED]> wrote:
>
> Unfortunately, no. I understand transaction isolation levels. By the way,
> I'm using MySQL InnoDB which has similar isolation level settings to
> PostgreSQL. Regardless of the isolation level, the one of the two
> concurrent
Unfortunately, no. I understand transaction isolation levels. By the
way, I'm using MySQL InnoDB which has similar isolation level settings
to PostgreSQL. Regardless of the isolation level, the one of the two
concurrent creates will fails. They are atomic and add data that will
voliate a UN
James Bennett wrote:
> Ultimately, the database is the only location from which you can solve
> this problem, because only the database can reliably know when these
> situations are occurring. Solutions implemented outside the DB are
> essentially doomed from the start.
>
> Similarly, an applicat
On Dec 4, 2007 3:08 PM, Travis Terry <[EMAIL PROTECTED]> wrote:
>
> I've run into a problem with get_or_create() with respect to concurrent
> access of the DB, and I have looked at the list archives for advice. I
> found some discussions a while back regarding other's problems but no
> acceptable
On 12/4/07, Travis Terry <[EMAIL PROTECTED]> wrote:
> Previous proposals to address this issue involved adding either a thread
> lock or a DB table lock around the get_or_create() call. Both of these
> are unacceptable. The thread lock does nothing to prevent the problem
> when using multiple fr
I've run into a problem with get_or_create() with respect to concurrent
access of the DB, and I have looked at the list archives for advice. I
found some discussions a while back regarding other's problems but no
acceptable solution was ever implemented. I have another proposed
solution that
14 matches
Mail list logo
