On 12/09/2014 02:16 PM, Rune Kaagaard wrote:
>
>>
>> A whole other issue is how to handle the deletion of already deleted
>> objects.
>>
> I misspoke here. I meant how to handle the deletion of an object with an
> outdated version number. Should it raise the same exception?
Yes, I think that d
>
> A whole other issue is how to handle the deletion of already deleted
> objects.
>
I misspoke here. I meant how to handle the deletion of an object with an
outdated version number. Should it raise the same exception?
--
You received this message because you are subscribed to the Google Gro
Hi Tim, Russell and Steven
I agree it would be more useful to be able to work with locking from all
places, not only the admin. The question then is how? :)
>From an implementation perspective, I also have a mild negative reaction to
> the idea of using a separate table in the database for lock
FWIW, this was on my mind a few years ago and I created this [1] ticket. It
spidered out into one or two more, but the basic ideas were:
* optimistic locking could be implemented by enhancing saves with
conditions (i.e., save_if)
* a row-modified count could help that function also tell you if the
Hi Rune,
I agree with Tim. This is clearly a problem that exists, and I agree it
would be good to fix it. However, I wouldn't want to see this as an "Admin
only" fix.
I'd rather see a generic hook that Admin then leverages as the "first
customer". A similar approach was taken with object-level pe
Hi Rune,
It's not clear to me that a fix that's coupled to the admin is the way to
go when this problem could exist for any model form, etc.
One ticket you didn't mention that seems like it could be a good place to
start is https://code.djangoproject.com/ticket/16549
Tim
On Monday, December 8
@Daniele
I struggled a bit with how to display the error message, and your solution
makes perfect sense.
Best,
Rune Kaagaard
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group
On Mon, Dec 8, 2014, Rune Kaagaard wrote:
>I've made a branch that adds optimistic concurrency control to the admin:
>https://github.com/runekaagaard/django-lock-the-admin/compare/adminlock. It
>works for the main change object and inlines and has tests. All tests
>passes with postgres and sql
Hi
I've made a branch that adds optimistic concurrency control to the admin:
https://github.com/runekaagaard/django-lock-the-admin/compare/adminlock. It
works for the main change object and inlines and has tests. All tests
passes with postgres and sqlite.
This prevents users from accidentally
