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

Question

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

JPA 支持 LocalDate、LocalTime、LocalDateTime 等，但不支持 Instant。当然，您可以使用 AttributeConverter 或一些库，例如 Jadira但为什么不支持开箱即用？

Answer 1

我会再试一次。 the issue中有一些讨论.最新的讨论好像是:

mkarg said: While that is absolutely correct, the technical answer is a bit more complex: What is the final predicate that makes a data type eligible for inclusion in the set of mandatory type mappings?

One could say, that predicate is "being essential" or "being of common use", but who defines what "essential" or "common use" is? See, for some applications, support for java.awt.Image and java.net.URL might be much more essential than support for LocalDate or ZonedDateTime. On the other hand, other applications might be full of LocalDate but never uses Instant. So where exactly to make the cut? This becomes particularly complex when looking at the sheer amount of types found in the JRE, and it is obvious there has to be a cut somewhere. Even JavaFX, which is bundled with the JRE, does not support Instant still in v8, so why should JPA? And looking at the current progress of Project Jigsaw, possibly the qualifying predicate might simply be answered by "all types in a particular jigsaw module"?

Anyways, it is not up to me to decide. I do support your request, and would love to see support for rather all Java Time API times, particularly for Instant and Duration, and your request has prominent supporters like for example Java Champion Arun Gupa as I learned recently. But I doubt the final answer will be as simple an satisfying as we would love to have it.

Maybe it would be better to simply set up another JSR, like "Common Data Type Conversions for the Java Platform", which provides much more mappings than just date and time, but also would not be bound to JPA but also could be used by JAXB, JAX-RS, and possibly more API that deal which the problem of transforming " to "? Having such a vehicle would really reduce boilerplate a lot.

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

有a new issue以便将其添加到 future 的 JPA 版本中。

我在 a thread 上发现的另一个有趣的分析通过 Douglas Surber (适用于 JDBC):

The JDK 8 version of JDBC includes support for most of the SQL types that correspond to 310 classes.

• DATE - LocalDate
• TIME - LocalTime
• TIMESTAMP WITH OUT TIME ZONE - LocalDateTime
• TIMESTAMP WITH TIME ZONE - OffsetDateTime

JDK 8 version of JDBC does not include a mapping between the INTERVAL types and the corresponding 310 classes.

There is no SQL type that exactly corresponds to any other 310 classes. As a result, the JDBC spec is silent for all other classes.

I would strongly encourage JDBC developers to use the new 310 classes. There are problems with java.util.Date, java.sql.Date, java.sql.Time, and java.sql.Timestamp. You should consider them deprecated. The 310 classes are vastly superior.

Douglas

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

最后，如果您通读 this thread保持标准 API 小而简单的文化压力似乎很大。