Code

Opened 5 years ago

Last modified 2 years 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: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
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.

Attachments (0)

Change History (9)

comment:1 Changed 5 years ago by epandurski

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 follow-up: Changed 5 years ago by mtredinnick

  • Owner mir@… deleted
  • Triage Stage changed from Unreviewed to Design 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 5 years ago by epandurski

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:4 Changed 5 years ago by epandurski

comment:5 Changed 5 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

comment:6 Changed 3 years ago by SmileyChris

  • Severity set to Normal
  • Type set to New feature

comment:7 in reply to: ↑ 2 Changed 3 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 3 years ago by lukeplant

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 Changed 2 years ago by aaugustin

  • Triage Stage changed from Design decision needed to Accepted
  • UI/UX unset

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new
The owner will be changed from (none) to anonymous. Next status will be 'assigned'
as The resolution will be set. Next status will be 'closed'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.