Opened 12 years ago

Last modified 4 weeks ago

#10088 new New feature

for_share() as well as for_update() addition to Model.QuerySet

Reported by: epandurski Owned by:
Component: Database layer (models, ORM) Version: 1.0
Severity: Normal Keywords:
Cc: Adam (Chainz) Johnson Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Ticket #2705 is a very good idea I think.

PostgreSQL supports SELECT ... FOR SHARE locking mode, which is basically
the same as FOR UPDATE mode but it does not conflicts with other transaction
having obtained FOR SHARE mode for the row.
It very useful if you need to be sure that your selected rows are not
modified since you have read them (which is true for almost every complex transaction).

I am not sure if MySQL has this feature but in PostgreSQL it first-class citizen so
I believe for_share() and for_update() has to be implemented together.

Change History (11)

comment:1 Changed 12 years ago by epandurski

comment:2 Changed 12 years ago by Malcolm Tredinnick

Owner: mir@… deleted
Triage Stage: UnreviewedDesign decision needed

Removing the list of people in the assigned field.

This is fairly orthogonal to for_update(). Django isn't meant to provide wrappers for every database feature under the sun, so we might not do this. Worth thinking about, however.

comment:3 Changed 12 years ago by epandurski

I did some googling for MySQL support for this feature. MySQL do
support it too (see

MS SQL Server supports this too through "WITH HOLDLOCK" hint if
my memory serves me well (see

I am sure Oracle does it too, nevertheless I have no reference to any documentation.

What I am trying to say is that FOR SHARE feature is not PostgreSQL-specific but
instead is essential tool to ensure data consistency (I would say *the right way*).

comment:4 Changed 12 years ago by epandurski

comment:5 Changed 11 years ago by (none)

milestone: post-1.0

Milestone post-1.0 deleted

comment:6 Changed 9 years ago by Chris Beaven

Severity: Normal
Type: New feature

comment:7 in reply to:  2 Changed 9 years ago by anonymous

Easy pickings: unset

Replying to mtredinnick:

Removing the list of people in the assigned field.

This is fairly orthogonal to for_update(). Django isn't meant to provide wrappers for every database feature under the sun, so we might not do this. Worth thinking about, however.

I'm finding this to be systemic in the Django community that makes the whole use of Django, in my opinion, not worthwhile. I feel like this attitude is what draws people away. There's also such a thing as being so abstract that it's completely useless and as a result people end up having to write .raw() a lot more than often.

Just a bit of a rant, but I'm really tired of seeing 4+ year old bugs or things that sit in the community only to see it get closed as "wontfix" or "let's debate about this really small change or issue for ever".

comment:8 Changed 9 years ago by Luke Plant


If you want to see a ticket moved on, there are ways to do it:

  • Bring it up on django-devs if it gets the 'DDN' status, bringing your arguments and asking for a decision - this is what the 'contributing to Django' docs tell you to do.
  • Implement a clean, tested, documented patch.

Or even better, do both - come to django-devs with your nice patch, proving that you are serious and the feature has a sensible implementation.

With neither of these done, it's difficult to take this complaint seriously, at least on this ticket. Are you really expecting someone else to do the work for this feature, either in terms of driving for a design decision, or implementing it? There are many worthy features that might be included in Django, and neither the core developers nor the rest of the community are making any promises to work on something just because it might be a good idea.



comment:9 Changed 9 years ago by Aymeric Augustin

Triage Stage: Design decision neededAccepted
UI/UX: unset

Assuming it's possible to implement this cleanly, it sounds useful.

comment:10 Changed 2 years ago by David Schwärzle

I was recently searching for a shared lock in Django and then came across this very old ticket. Because not using locks is in some cases dangerous and exclusive locks are less efficient for read only operations I think this should be implemented in Django.

So I created a quick and dirty monkey patch which adds this feature for MySQL and MariaDB syntax to Django including MariaDBs (>10.3.0) "WAIT <seconds>" feature. The patch is ~400 lines long, but most of that are blank lines and copied Django functions. I am not very experienced with Python nor with Django, so I probably won't implement it properly and create a pull request, but I'll upload the patch if someone is still interested.

comment:11 Changed 4 weeks ago by Adam (Chainz) Johnson

Cc: Adam (Chainz) Johnson added
Note: See TracTickets for help on using tickets.
Back to Top