tickets: 10088
This data as json
| id | created | changetime | last_pulled_from_trac | stage | status | component | type | severity | version | resolution | summary | description | owner | reporter | keywords | easy | has_patch | needs_better_patch | needs_tests | needs_docs | ui_ux |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 10088 | 2009-01-21 22:12:38 | 2020-07-09 16:19:08 | 2022-03-06 03:46:25.658777 | Accepted | new | Database layer (models, ORM) | New feature | Normal | 1.0 | for_share() as well as for_update() addition to Model.QuerySet | 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. | epandurski | 0 | 0 | 0 | 0 | 0 | 0 |