tickets: 11156
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 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 11156 | 2009-05-20 10:24:55 | 2013-03-11 21:58:48 | 2022-03-06 03:49:14.909468 | Accepted | new | Database layer (models, ORM) | Cleanup/optimization | Normal | dev | Unnecessary savepoints with Oracle | Savepoints are implemented in the Postgresql and Oracle backends, and provide a useful features to users of both. In addition, the framework itself wraps various calls in savepoints (e.g. inside django/db/models/query.py:get_or_create). This is to work around a Postgresql-specific oddity that the open transaction needs to be rolled back to a prior savepoint if it experiences a database exception. This oddity is not present on Oracle, so the extra savepoints are not required. We probably need to split the current single backend flag uses_savepoints into two: can_savepoint and needs_savepoint_after_exception. See http://groups.google.com/group/django-developers/browse_thread/thread/bca33ecf27ff5d63 | Richard Davies <richard.davies@elastichosts.com> | oracle savepoints | 0 | 1 | 0 | 1 | 0 | 0 |