I feel that you are better off disabling autocommit and managing your own
transactions, docs here:
https://docs.djangoproject.com/en/1.9/topics/db/transactions/
But no doubt I am missing something in your plans. You would need multiple
transactions or you would have performance problems due to
In my opinion SELECT ... FOR UPDATE is already quite powerful to add locks.
Might not be as good as a straight table lock, but gives you enough power
to lock by rows (select some indexed columns, most dbs will lock only rows
matching them) or select by a non indexed column which will probably
I don't think any abstraction is possible. Postgres has 8 different
table-level locking modes, in addition to advisory locks and 4 row-level
lock modes. I would say any attempt to abstract that would remove
functionality, and that would not be convenient.
We are already suffering from an
On 03/05/16 14:08, Gavin Wahl wrote:
> with MyModel.objects.lock():
> ... do stuff ...
This is misleading as it implies the lock is released when the context
manager exists, but in postgres at least the lock will be held until the
end of the transaction.
Hah! Shows how much I
> with MyModel.objects.lock():
> ... do stuff ...
This is misleading as it implies the lock is released when the context
manager exists, but in postgres at least the lock will be held until the
end of the transaction.
What advantage does implementing an ORM API for table locking
On 03/05/16 09:47, Russell Keith-Magee wrote:
Hi Geoffrey
Have you given any thought to what the API for a table lock would look like?
Since it's a table-wide action, having it on the Manager makes some
sense... though it would be, I suspect, implemented via _meta.
I can see something
Hi Geoffrey
On Tue, May 3, 2016 at 3:42 AM, Geoffrey Martin-Noble wrote:
> Is there a particular reason Django doesn't implement table locks? These
> are vendor-specific, but seem to be common to various SQL backends, which
> is something Django generally does well.
>
Is there a particular reason Django doesn't implement table locks? These
are vendor-specific, but seem to be common to various SQL backends, which
is something Django generally does well.
I am working on an application in which I would like to be able to perform
bulk create on inherited