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 , 16 years ago
follow-up: 7 comment:2 by , 16 years ago
Owner: | removed |
---|---|
Triage Stage: | Unreviewed → Design decision needed |
comment:3 by , 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:4 by , 16 years ago
Uuups... I pasted the wrong link to MySQL. Sorry.
http://www.mysqlperformanceblog.com/2006/08/06/select-lock-in-share-mode-and-for-update/
comment:6 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → New feature |
comment:7 by , 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 , 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 , 13 years ago
Triage Stage: | Design decision needed → Accepted |
---|---|
UI/UX: | unset |
Assuming it's possible to implement this cleanly, it sounds useful.
comment:10 by , 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 , 4 years ago
Cc: | added |
---|
comment:12 by , 2 years ago
Keywords: | select_for_share added |
---|---|
Needs documentation: | set |
Needs tests: | set |
Owner: | set to |
Status: | new → assigned |
Version: | 1.0 → dev |
i am so new , but i want try
comment:14 by , 2 years ago
Needs documentation: | unset |
---|---|
Needs tests: | unset |
Owner: | changed from | to
New PR.
comment:15 by , 2 years ago
Patch needs improvement: | set |
---|
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.