← Back to branch summary

~drizzle-trunk/drizzle/development

« back to all changes in this revision

Viewing changes to tests/t/microsecond.test

* Fixes drizzled's atomics:

- fetch_and_add() was actually add_and_fetch() - fixed to have both methods correct
- compare_and_swap() was incorrect for all traits classes.  Fixed to return a bool
true only when the supplied value is actually swapped
- fixes increment() and decrement() methods and operator+=() in outer atomics class
template to call proper add_and_fetch() methods on traits classes
- Now that above are fixed, removed the hacks in Query_id and TransactionLog to
have query ID and the new transactoin ID start properly at 1.

* Transaction messages sent over replication stream now use
a real transaction ID, managed by drizzled::TransactionServices.  Previously, 
the Query_id was being used, resulting in SELECT statements incrementing the
transaction ID.

* Added a test case to ensure that DDL ops are given a transaction ID and SELECT
ops do not increment the transaction ID.

The transaction ID will be paired with a channel ID to become the global
transaction identifier.  ReplicationServices will manage the pairing of
channel and transaction ID and understand how far a particular subscriber
node has applied.

Show diffs side-by-side

added added

removed removed

Lines of Context:
tests/t/microsecond.test
16
16
# Test improper argument list 
17
17
#
18
18
# 1 arg is required.
19
 
--error ER_PARSE_ERROR 
 
19
--error 1064 
20
20
# Wrong parameter count...but unfortunately produces 1064 Syntax Error due to limitations of 
21
21
# the SQL parser, which considers MICROSECOND a keyword before being a function symbol
22
22
SELECT MICROSECOND();
23
 
--error ER_PARSE_ERROR
 
23
--error 1064
24
24
# Wrong parameter count...but unfortunately produces 1064 Syntax Error due to limitations of 
25
25
# the SQL parser, which considers MICROSECOND a keyword before being a function symbol
26
26
SELECT MICROSECOND(1, 0);
30
30
# produce an error, not a NULL or anything
31
31
# else...
32
32
#
33
 
--error ER_INVALID_DATETIME_VALUE
 
33
--error 1686
34
34
SELECT MICROSECOND("xxx");
35
35
 
36
36
# 
39
39
# The following are all bad dates, with no possibility of interpreting
40
40
# the values as TIME-only components.
41
41
#
42
 
--error ER_INVALID_DATETIME_VALUE
 
42
--error 1686
43
43
SELECT MICROSECOND("0000-00-00"); # No 0000-00-00 dates!...
44
 
--error ER_INVALID_DATETIME_VALUE
 
44
--error 1686
45
45
SELECT MICROSECOND("0000-01-01"); # No zero year parts
46
 
--error ER_INVALID_DATETIME_VALUE
 
46
--error 1686
47
47
SELECT MICROSECOND("0001-00-01"); # No zero month parts
48
 
--error ER_INVALID_DATETIME_VALUE
 
48
--error 1686
49
49
SELECT MICROSECOND("0001-01-00"); # No zero day parts
50
 
--error ER_INVALID_DATETIME_VALUE
 
50
--error 1686
51
51
SELECT MICROSECOND("2000-02-30"); # No Feb 30th!
52
 
--error ER_INVALID_DATETIME_VALUE
 
52
--error 1686
53
53
SELECT MICROSECOND("1900-02-29"); # Not a leap MICROSECOND since not divisible evenly by 400...
54
 
--error ER_INVALID_DATETIME_VALUE
 
54
--error 1686
55
55
SELECT MICROSECOND('1976-15-15'); # No 15th month!
56
 
--error ER_INVALID_DATETIME_VALUE
 
56
--error 1686
57
57
SELECT MICROSECOND('23:59:70'); # No 70th second!
58
 
--error ER_INVALID_DATETIME_VALUE
 
58
--error 1686
59
59
SELECT MICROSECOND('23:70:59'); # No 70th minute!
60
 
--error ER_INVALID_DATETIME_VALUE
 
60
--error 1686
61
61
SELECT MICROSECOND('26:00:00'); # No 26th hour!
62
 
--error ER_INVALID_DATETIME_VALUE
 
62
--error 1686
63
63
SELECT MICROSECOND('26:00:00.9999999'); # Microseconds are 6 places, not 7
64
64
 
65
65
# A good date, which cannot be interpreted as a TIME component.  Should return 0.