If you read over the linked discussion it's quite possible, just an issue
of how disruptive it would be to the ORM APIs.
On Saturday, June 30, 2012, Dennis Lee Bieber wrote:
> On Sat, 30 Jun 2012 15:24:59 -0700 (PDT), ydjango
>
> >
> declaimed the following in gmane.comp.python.django.user:
>
>
I started looking into it a while back:
https://code.djangoproject.com/ticket/16549
The work broke down into ensuring that the updated/deleted/matched counts
were returned from the internal ORM objects. Then there was a fair amount
of discussion of what the public API of the ORM could provide on t
Hello,
I've recently been tackling almost the same thing. I'm using Google App
Engine and app-engine-patch so I can't help you on the best method for
implementing the optimistic locking at the database level to avoid race
conditions (though I'm even more lost as to how to achieve the same thing
us
On Monday 04 Feb 2008, Michael Hipp wrote:
> Tim Sawyer wrote:
> > If you're going to do that, then couldn't we change the framework to add
> > a new VersionField. If there is a VersionField defined on the object,
> > then the code on save could automatically be added. This VersionField
> > woul
Tim Sawyer wrote:
> On Sunday 03 Feb 2008, code_berzerker wrote:
>> How about rewriting save method complately and make additional
>> condition in WHERE clausule like this:
>> UPDATE ... WHERE id=666 AND mtime=object_mtime
>> Checking number of updated rows would give you information about
>>
On Sunday 03 Feb 2008, code_berzerker wrote:
> How about rewriting save method complately and make additional
> condition in WHERE clausule like this:
> UPDATE ... WHERE id=666 AND mtime=object_mtime
> Checking number of updated rows would give you information about
> success and would guarant
How about rewriting save method complately and make additional
condition in WHERE clausule like this:
UPDATE ... WHERE id=666 AND mtime=object_mtime
Checking number of updated rows would give you information about
success and would guarantee that there is no data manipulation between
mtime che
> Could you explain how this works, please?
>
> It looks - to my uneducated eyes - if this leaves open a potential race
> condition where the mtime field could yet be changed in the database by
> another process within the "decision time" of this method. Do I
> misunderstand? It seems to me that t
Thomas Guettler wrote:
> Am Donnerstag, 24. Januar 2008 13:08 schrieb Tim Sawyer:
>> Hi Folks,
>>
>> I'm just evaluating django for use on a project. I have a multiuser
>> application where many users can be changing data at once.
>>
>> What's the status of hibernate style optimistic locking, whe
Am Montag, 28. Januar 2008 10:16 schrieb Alistair Lattimore:
> Thomas,
>
> Do you use a custom manager to select out the row before issuing the
> save to make sure that the in memory timestamp matches that of the
> database?
>
No, since I don't use caching the mtime should be 'fresh'. Since
I use
Thomas,
Do you use a custom manager to select out the row before issuing the
save to make sure that the in memory timestamp matches that of the
database?
Al.
On Jan 24, 11:16 pm, Thomas Guettler <[EMAIL PROTECTED]> wrote:
> Am Donnerstag, 24. Januar 2008 13:08 schrieb Tim Sawyer:
>
> > Hi Folks
Am Donnerstag, 24. Januar 2008 13:08 schrieb Tim Sawyer:
> Hi Folks,
>
> I'm just evaluating django for use on a project. I have a multiuser
> application where many users can be changing data at once.
>
> What's the status of hibernate style optimistic locking, where each object
> has a version
On 7/31/07, Victor Ng <[EMAIL PROTECTED]> wrote:
>
> Has anyone looked into implementing optimistic locking for the Django ORM?
>
> I didn't see anything logged into code.djangoproject.com or in the
> django-users list.
>
> Has anyone taken a stab at implementing this yet?
I haven't looked into t
13 matches
Mail list logo
