我正在测试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
出现。
结果,我无法选择或更改表的当前状态。这是错误还是我错过了一些配置选项,以及使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]>
答案 0 :(得分:0)
您可能在附近,但不会出现。和我一起进行思想练习...
19年前,MySQL在版本3.xx中仅运行MyISAM。 Windows运行的版本除非您保存了旧硬件,否则今天将无法运行。而且它的内存远远少于1GB,并且备份可能在软盘上。 (还记得软盘吗?)显示设备是一个通过VGA电缆连接的CRT。 (您上次看到CRT是什么时候?)
您会相信任何古老的东西吗?您甚至可以运行它吗?
你怎么能活19年?您必须每5年 升级一切-硬件,输入设备,输出设备,内存,存储,操作系统,MySQL等。
前进19年。
我声称从现在到2038年,您将需要进行4次重大升级。处理Y-2038问题只是一件小事。
如果您确实需要向前看,则至少可以使用DATE
直到出现Y10K问题。在我们死后不久。
答案 1 :(得分:0)
以下是有关DATETIME
和系统版本表的讨论。简而言之,这是有意禁止的,总有一天会有一个范围更广的数据类型。 https://jira.mariadb.org/browse/MDEV-17448