我正在测试mariadb 10.3.9中的系统版本表,但我想更新以前的版本 2038-01-19 03:14:07.999999
因为我想我在19年后还能活着。为此,我正在使用 DATETIME(6)
而不是 TIMESTAMP(6)
. 这不管用。这个 AS ROW END
一代又一代 0000-00-00 00:00:00.000000
.
因此,我无法选择或更改表的当前状态。这是一个bug还是我遗漏了一些配置选项、实现细节 DATETIME
不可行?
以下是测试会话的打印输出:
MariaDB [tests]> CREATE TABLE dateTimeTest
-> (
-> dtt_id INT UNSIGNED NOT NULL AUTO_INCREMENT,
-> dtt_value VARCHAR(6) NOT NULL,
-> dtt_rowStart DATETIME(6) GENERATED ALWAYS AS ROW START,
-> dtt_rowEnd DATETIME(6) GENERATED ALWAYS AS ROW END,
-> PERIOD FOR SYSTEM_TIME(dtt_rowStart, dtt_rowEnd),
-> --
-> PRIMARY KEY DTT_pk(dtt_id)
-> ) WITH SYSTEM VERSIONING;
Query OK, 0 rows affected (0.057 sec)
MariaDB [tests]> INSERT INTO dateTimeTest (dtt_value)
-> VALUES ('valueA'),
-> ('valueB');
Query OK, 2 rows affected (0.009 sec)
Records: 2 Duplicates: 0 Warnings: 0
MariaDB [tests]> SELECT *
-> FROM dateTimeTest;
Empty set (0.000 sec)
MariaDB [tests]> SELECT * FROM dateTimeTest FOR SYSTEM_TIME ALL;
+--------+-----------+----------------------------+----------------------------+
| dtt_id | dtt_value | dtt_rowStart | dtt_rowEnd |
+--------+-----------+----------------------------+----------------------------+
| 1 | valueA | 2018-10-04 20:49:50.763456 | 0000-00-00 00:00:00.000000 |
| 2 | valueB | 2018-10-04 20:49:50.763456 | 0000-00-00 00:00:00.000000 |
+--------+-----------+----------------------------+----------------------------+
2 rows in set (0.000 sec)
MariaDB [tests]>
2条答案
按热度按时间2izufjch1#
这里有一些关于
DATETIME
和系统版本表。简而言之,这是故意不允许的,总有一天会有一个范围更广的数据类型。https://jira.mariadb.org/browse/mdev-17448j8ag8udp2#
你可能在附近,但不会。和我一起做一个思考练习。。。
19年前,mysql的版本是3.xx,只运行myisam。windows运行的版本如果不保存旧的硬件就不会运行。而且它只有不到1gb的ram,而且备份可能是失败的(还记得软盘吗?)显示设备是一个用vga电缆连接的crt(你最后一次看到crt是什么时候?)
你会相信那么古老的东西吗?你能让它跑起来吗?
你怎么能让一个东西活19年?你必须每5年升级一次硬件、输入设备、输出设备、内存、存储、操作系统、mysql等等。
向前移动19年。
我声称从现在到2038年你将需要做4次主要的升级。处理y-2038问题只是一件小事。
如果你确实需要向前看,你至少可以使用
DATE
直到y10k问题出现。在我们死后很久。