Re: [Django] #11156: Unnecessary savepoints with Oracle
Django
-------------------------------------+-------------------------------------
Reporter: Richard Davies | Owner: aaugustin
<richard.davies@…> | Status: assigned
Type: | Version: master
Cleanup/optimization | Resolution:
Component: Database layer | Triage Stage: Accepted
(models, ORM) | Needs documentation: 0
Severity: Normal | Patch needs improvement: 0
Keywords: oracle savepoints | UI/UX: 0
Has patch: 1 |
Needs tests: 1 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by aaugustin):
* owner: nobody => aaugustin
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/11156#comment:13>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: Richard Davies | Owner:
Type: | Version: master
Cleanup/optimization | Resolution:
Component: Database layer | Triage Stage: Accepted
(models, ORM) | Needs documentation: 0
Severity: Normal | Patch needs improvement: 0
Keywords: oracle savepoints | UI/UX: 0
Has patch: 1 |
Needs tests: 1 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by aaugustin):
* owner: aaugustin =>
* status: assigned => new
Comment:
I would rather qualify this as an Oracle oddity: apparently, Oracle
transactions don't guarantee integrity!
For example in the following scenario:
- enter a transaction
- execute a statement A that succeeds
- execute a statement B that fails because of an integrity error; it's
automatically rolled back
- execute a statement C that succeeds
- commit the transaction
you get only the changes resulting from A and C.
I thought transactions were supposed to guarantee that either all the
changes were going to be committed or none of them.
----
I'd like to see a benchmark of how much the extra savepoints hurt before
adding new flags and conditionals to the ORM.
This appears rather orthogonal to my recent work on transactions, so I'm
going to deassign myself.
--
Ticket URL: <https://code.djangoproject.com/ticket/11156#comment:14>
Django
-------------------------------------+-------------------------------------
Reporter: Richard Davies | Owner:
<richard.davies@…> | Status: new
Type: | Version: master
Cleanup/optimization | Resolution:
Component: Database layer | Triage Stage: Accepted
(models, ORM) | Needs documentation: 0
Severity: Normal | Patch needs improvement: 0
Keywords: oracle savepoints | UI/UX: 0
Has patch: 1 |
Needs tests: 1 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by ikelly):
It's a bit weird, I agree. The Oracle docs refer to this as "statement-
level atomicity":
[http://docs.oracle.com/cd/E11882_01/server.112/e10713/transact.htm]
Transactions are guaranteed to be atomic (e.g. in case of system failure),
but an unsuccessful statement is not considered part of the transaction.
--
Ticket URL: <https://code.djangoproject.com/ticket/11156#comment:15>
Django
-------------------------------------+-------------------------------------
Reporter: Richard Davies | Owner:
<richard.davies@…> | Status: new
Type: | Version: master
Cleanup/optimization | Resolution:
Component: Database layer | Triage Stage: Accepted
(models, ORM) | Needs documentation: 0
Severity: Normal | Patch needs improvement: 0
Keywords: oracle savepoints | UI/UX: 0
Has patch: 1 |
Needs tests: 1 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by aaugustin):
To implement this, Oracle must create some sort of "implicit savepoint"
before every statement. Indeed, that means that it's never required to
create a savepoint around a single statement on Oracle.
It could be much worse, see ''Response To Errors Within A Transaction'' in
http://www.sqlite.org/lang_transaction.html :)
--
Ticket URL: <https://code.djangoproject.com/ticket/11156#comment:16>
Django
-------------------------------------+-------------------------------------
<richard.davies@…> |
Type: | Status: closed
Cleanup/optimization |
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: oracle savepoints | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Simon Charette):
* status: new => closed
* resolution: => wontfix
Comment:
I'm going to wont-fix this one.
No conversation update for the past 9 years and still no performance
benchmarks demonstrating that it is a change worth the extra complexity it
introduces.
The transaction logic is already complex and Oracle has proven to be the
hardest backend to support for the past years. I'm far from convinced than
attempting to take advantage of this
[https://docs.oracle.com/cd/E11882_01/server.112/e40540/transact.htm#CNCPT1115
statement-level atomicity feature] will bring more benefits than the
maintenance burden it will incur.
--
Ticket URL: <https://code.djangoproject.com/ticket/11156#comment:17>