Opened 16 years ago

Last modified 2 years ago

#10088 assigned New feature

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

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

Description

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.
(see http://www.postgresql.org/docs/8.3/static/sql-select.html#SQL-FOR-UPDATE-SHARE)
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 (15)

comment:1 by epandurski, 16 years ago

comment:2 by Malcolm Tredinnick, 16 years ago

Owner: mir@… removed
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 by epandurski, 16 years ago

I did some googling for MySQL support for this feature. MySQL do
support it too (see http://code.djangoproject.com/ticket/1008).

MS SQL Server supports this too through "WITH HOLDLOCK" hint if
my memory serves me well (see http://msdn.microsoft.com/en-us/library/ms187373.aspx)

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:5 by (none), 16 years ago

milestone: post-1.0

Milestone post-1.0 deleted

comment:6 by Chris Beaven, 14 years ago

Severity: Normal
Type: New feature

in reply to:  2 comment:7 by anonymous, 14 years ago

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 by Luke Plant, 14 years ago

anonymous:

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.

Thanks,

Luke

comment:9 by Aymeric Augustin, 13 years ago

Triage Stage: Design decision neededAccepted
UI/UX: unset

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

comment:10 by David Schwärzle, 6 years ago

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 by Adam Johnson, 4 years ago

Cc: Adam Johnson added

comment:12 by xyd, 2 years ago

Keywords: select_for_share added
Needs documentation: set
Needs tests: set
Owner: set to xyd
Status: newassigned
Version: 1.0dev

i am so new , but i want try

comment:13 by Keryn Knight, 2 years ago

Has patch: set

comment:14 by Nick Pope, 2 years ago

Needs documentation: unset
Needs tests: unset
Owner: changed from xyd to Nick Pope

New PR.

comment:15 by Mariusz Felisiak, 2 years ago

Patch needs improvement: set
Note: See TracTickets for help on using tickets.
Back to Top