1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
|
# Tests of various SAVEPOINT functionality
# Test for Bug #534806 - SAVEPOINT without active transaction
# triggers assert in InnoDB handler
SET AUTOCOMMIT = 0;
CREATE TABLE t1 (id INT NOT NULL PRIMARY KEY);
COMMIT;
UPDATE t1 SET id = 2 WHERE id != 2 LIMIT 0;
SAVEPOINT A;
DROP TABLE t1;
# Let's test the non-edge case for SAVEPOINTS:
#
# Typical usage pattern of starting a transaction, doing
# some work, savepointing, do more work, savepointing, etc
# and committing without any rollbacks or savepoint releases.
CREATE TABLE t1 (id INT NOT NULL PRIMARY KEY);
START TRANSACTION;
INSERT INTO t1 VALUES (1);
SAVEPOINT A;
INSERT INTO t1 VALUES (2);
SAVEPOINT B;
INSERT INTO t1 VALUES (3);
COMMIT;
# t1 should now have 1,2,3 in it.
SELECT * FROM t1;
# We now test another typical usage pattern, similar to above,
# but we issue a ROLLBACK at the end instead of a COMMIT. All
# work done in all savepoints should be rolled back.
START TRANSACTION;
INSERT INTO t1 VALUES (4);
SAVEPOINT A;
INSERT INTO t1 VALUES (5);
SAVEPOINT B;
INSERT INTO t1 VALUES (6);
ROLLBACK;
# t1 should still have 1,2,3 in it.
SELECT * FROM t1;
# We now test the final typical usage pattern, where we
# ROLLBACK work to a specific SAVEPOINT and then COMMIT.
START TRANSACTION;
INSERT INTO t1 VALUES (4);
SAVEPOINT A;
INSERT INTO t1 VALUES (5);
SAVEPOINT B;
INSERT INTO t1 VALUES (6);
ROLLBACK TO SAVEPOINT A;
COMMIT;
# t1 should have 1,2,3,4 in it.
SELECT * FROM t1;
DROP TABLE t1;
|