在mariadb 10.3.9系统版本表中使用datetime适用于rowstart,但不适用于rowend

hwamh0ep  于 2021-06-20  发布在  Mysql
关注(0)|答案(2)|浏览(273)

我正在测试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]>
2izufjch

2izufjch1#

这里有一些关于 DATETIME 和系统版本表。简而言之,这是故意不允许的,总有一天会有一个范围更广的数据类型。https://jira.mariadb.org/browse/mdev-17448

j8ag8udp

j8ag8udp2#

你可能在附近,但不会。和我一起做一个思考练习。。。
19年前,mysql的版本是3.xx,只运行myisam。windows运行的版本如果不保存旧的硬件就不会运行。而且它只有不到1gb的ram,而且备份可能是失败的(还记得软盘吗?)显示设备是一个用vga电缆连接的crt(你最后一次看到crt是什么时候?)
你会相信那么古老的东西吗?你能让它跑起来吗?
你怎么能让一个东西活19年?你必须每5年升级一次硬件、输入设备、输出设备、内存、存储、操作系统、mysql等等。
向前移动19年。
我声称从现在到2038年你将需要做4次主要的升级。处理y-2038问题只是一件小事。
如果你确实需要向前看,你至少可以使用 DATE 直到y10k问题出现。在我们死后很久。

相关问题