为什么 JPA 不支持 java.time.Instant？

java jpa java.time.instant

2022-09-01 13:27:22

我认为这是将日期存储到数据库中的最佳选择：它最有可能是TIMESTAMP，您不依赖于时区，它只是时间上的一个时刻。java.time.Instant

JPA 支持、等，但不支持即时。当然，您可以使用其中一个或一些库，例如Jadira，但是为什么它不支持开箱即用？LocalDateLocalTimeLocalDateTimeAttributeConverter

答案 1

我会再试一次。在这个问题上有一些讨论。最新的讨论似乎是：

mkarg说：“虽然这是绝对正确的，但技术答案有点复杂：使数据类型有资格包含在强制类型映射集中的最终谓词是什么？

可以说，谓词是“本质”或“共同使用”，但谁来定义“必要”或“共同使用”是什么？请参阅，对于某些应用程序，对 java.awt.Image 和 java.net.URL 的支持可能比对 LocalDate 或 ZonedDateTime 的支持更重要。另一方面，其他应用程序可能充满了LocalDate，但从未使用Instant。那么，究竟在哪里进行切割呢？当查看JRE中发现的大量类型时，这变得特别复杂，很明显，必须在某个地方进行切割。即使是与JRE捆绑在一起的JavaFX，在v8中仍然不支持Instant，那么为什么JPA呢？看看Project Jigsaw的当前进展，也许限定谓词可以简单地用“特定拼图模块中的所有类型”来回答？

无论如何，这不是由我决定的。我确实支持你的请求，并且希望看到对所有Java Time API时间的支持，特别是对即时和持续时间的支持，并且你的请求有突出的支持者，例如我最近学到的Java Champion Arun Gupa。但我怀疑最终的答案会像我们希望的那样简单，令人满意。

也许简单地设置另一个JSR会更好，比如“Java平台的通用数据类型转换”，它提供了比日期和时间更多的映射，而且也不会绑定到JPA，但也可以被JAXB，JAX-RS使用，可能还有更多的API来处理转换“到”的问题？拥有这样的车辆确实会大大减少样板。

TL-DR;有很多类型。我们必须在某个地方划清界限。

有一个新问题需要将其添加到将来的 JPA 版本中。

我在Douglas Surber（在JDBC上工作）的帖子上发现的另一个有趣的分析：

JDK 8 版本的 JDBC 包括对与 310 类对应的大多数 SQL 类型的支持。

日期 - 本地日期

时间 - 本地时间

带输出时区的时间戳 - 本地日期时间

带时区的时间戳 - 偏移日期时间

JDK 8 版本的 JDBC 不包含 INTERVAL 类型和相应的 310 类之间的映射。

没有与任何其他 310 类完全对应的 SQL 类型。因此，JDBC 规范对于所有其他类都是无提示的。

我强烈建议 JDBC 开发人员使用新的 310 类。java.util.Date、java.sql.Date、java.sql.Time 和 java.sql.Timestamp 存在问题。您应该认为它们已弃用。310个班级远远优越。

道格拉斯

TL：DR;我们只是为在数据库中存储时态数据的 4 种可能方式中的每一种选择了一种 Java 8 类型。

最后，如果您通读此主题，似乎存在巨大的文化压力，以保持标准API的小型和简单性。

答案 2

这不是 JPA 问题，而是 JDBC 问题。

JDBC 支持 Date、Timestamp、LocalDate、LocalTime 和 LocalDateTime，但不支持 Instant。

这不是Java问题，而是SQL问题，其中存储在数据库中的内容是年-月-日-小时-分钟-秒构造。

想想SQL函数：YEAR（） MONTH（）等...

自1970年以来，这些函数不能应用于简单的毫秒数。它们确实需要 LocalDateTime 构造来执行这些功能。