On Thu, Aug 11, 2011 at 12:06 PM, Steven Cummings wrote:
> On Thu, Aug 11, 2011 at 11:14 AM, Simon Riggs wrote:
>
>> IDEA 2
>> (1) SELECT data & version
>> (2) UPDATE data & test version & COMMIT immediately
>>
>
> This is pretty much where I started when I initiated the ticket and thread
> and st
On Thu, Aug 11, 2011 at 11:14 AM, Simon Riggs wrote:
> IDEA 2
> (1) SELECT data & version
> (2) UPDATE data & test version & COMMIT immediately
>
This is pretty much where I started when I initiated the ticket and thread
and still am at. The other discussion here is what happens when the test
fa
On Wed, Aug 10, 2011 at 3:08 PM, Anssi Kääriäinen
wrote:
> On 08/10/2011 03:18 PM, Simon Riggs wrote:
>
> That adds additional SELECT statements, which then extends a lock
> window between the check statement and the changes. It works, but in
> doing so it changes an optimistic lock into a pessimi
On 08/10/2011 03:18 PM, Simon Riggs wrote:
That adds additional SELECT statements, which then extends a lock
window between the check statement and the changes. It works, but in
doing so it changes an optimistic lock into a pessimistic lock.
True. The issue I am trying to solve is: Guard against
On Tue, Aug 9, 2011 at 1:33 PM, akaariai wrote:
> On Aug 9, 1:17 am, Steven Cummings wrote:
>> I don't think we're talking about new or specific fields as part of the base
>> implementation here. Just enhanced behavior around updates to:
>>
>> 1) Provide more information about the actual rows mod
On Aug 9, 1:17 am, Steven Cummings wrote:
> I don't think we're talking about new or specific fields as part of the base
> implementation here. Just enhanced behavior around updates to:
>
> 1) Provide more information about the actual rows modified
> 2) Check preconditions with the actual DB store
I don't think we're talking about new or specific fields as part of the base
implementation here. Just enhanced behavior around updates to:
1) Provide more information about the actual rows modified
2) Check preconditions with the actual DB stored values; and
3) Avoid firing post-update/delete sig
On Aug 8, 6:30 pm, Steven Cummings wrote:
> For backward compatibility, there may be a Model sub-class that would leave
> Model alone altogether (this was suggested on the ticket). This seems fair
> since many seem to be getting by without better optimistic concurrency
> control from Django's ORM
For backward compatibility, there may be a Model sub-class that would leave
Model alone altogether (this was suggested on the ticket). This seems fair
since many seem to be getting by without better optimistic concurrency
control from Django's ORM today.
--
Steven
On Mon, Aug 8, 2011 at 9:40 AM,
On Aug 8, 4:54 pm, Steven Cummings wrote:
> Interesting feature I hadn't noticed in memcached. That does seem like it
> would do the trick where memcached is being used. I think the ability to
> control it in Django would generally still be desirable though, as that is
> where the data ultimately
Interesting feature I hadn't noticed in memcached. That does seem like it
would do the trick where memcached is being used. I think the ability to
control it in Django would generally still be desirable though, as that is
where the data ultimately lives and I'd be hesitant to assume to control the
Essentially, you want a compare-and--swap instruction for a database?
Have you considered using memcached atomicity (add and cas) to handle this
kind of thing? It might get pretty elaborate, but with just a cursory
thought seems doable.
-peter
On Sat, Aug 6, 2011 at 9:59 PM, Steven Cummings wrot
Bad community member that I am, I jumped the gun and logged a ticket
[1] on this one... anyway:
Websites general avoid overly aggressive locking of data to deal with
concurrency issues. When two users allowed to edit some data are
simultaneously doing so, they're both allowed to do so and the
last
13 matches
Mail list logo
