为什么JPA不支持java.time.Instant? [英] Why JPA does not support java.time.Instant?
问题描述
我认为java.time.Instant是将日期存储到数据库中的最佳选择:它很可能是 TIMESTAMP ，并且您不必依赖时区，只是时间上的一刻.
I think that java.time.Instant is the best choice to store a date into DB: it is the most likely TIMESTAMP and you are not depending by timezone, it is just a moment on the time.
JPA支持LocalDate，LocalTime，LocalDateTime等，但不支持Instant.当然，您可以使用AttributeConverter或诸如 Jadira 之类的某些库，但是为什么不支持现成的库?
JPA supports LocalDate, LocalTime, LocalDateTime etc. but not Instant. Sure, you can use either AttributeConverter or some libraries like Jadira but why it isn't supported out of the box?
推荐答案
我将再次尝试.在问题中进行了一些讨论.最新的讨论似乎是:
I'll try this again. There is some discussion in the issue. The latest discussion seems to be:
mkarg说:虽然这是绝对正确的，但技术上的答案是 稍微复杂一点:构成数据类型的最终谓词是什么 有资格包含在强制类型映射集中吗?
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?
可以说谓词是必不可少的"或是共同的" 使用"，但谁来定义什么是必要"或常用"呢? 某些应用程序，可能支持java.awt.Image和java.net.URL 比支持LocalDate或ZonedDateTime更重要.在 另一方面，其他应用程序可能充满了LocalDate，但是 从不使用Instant.那么到底要在哪里切割呢?这变成 当查看大量类型时特别复杂 在JRE中，很明显必须在某处进行裁员.甚至 与JRE捆绑在一起的JavaFX不支持Instant Still 在v8中，为什么要使用JPA?并看一下当前的进展 拼图项目，可能合格的谓词可能只是 回答特定拼图模块中的所有类型"?
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"?
无论如何，这不是我决定的.我支持您的要求，并且 很想看到对所有Java Time API时间的支持， 尤其是对于即时"和持续时间"，您的要求突出 我所了解到的支持者例如Java Champion Arun Gupa 最近.但我怀疑最终的答案是否会如此简单令人满意 如我们所愿.
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.
也许最好设置另一个JSR，例如"Common Java平台的数据类型转换"，它提供了更多信息 映射不只是日期和时间，而且也不会绑定到JPA 但也可以由JAXB，JAX-RS和可能更多的API使用 处理将转换为"的问题?有这样的车辆 确实会大大减少样板.
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；有很多类型.我们必须在某处画线.
存在新问题，将其添加到未来的JPA版本.
There is a new issue for it to be added to a future JPA version.
我在一个线程上发现的另一有趣的分析a href ="http://wiki.c2.com/?DouglasSurber" rel ="nofollow noreferrer"> Douglas Surber (适用于JDBC):
Another interesting bit of analysis I found on a thread by Douglas Surber (works on JDBC):
JDK 8版本的JDBC包括对大多数SQL类型的支持 对应于310个班级.
The JDK 8 version of JDBC includes support for most of the SQL types that correspond to 310 classes.
DATE-本地日期 TIME-LocalTime 没有时区的时间戳-LocalDateTime 带时区的时间戳-OffsetDateTime
DATE - LocalDate TIME - LocalTime TIMESTAMP WITH OUT TIME ZONE - LocalDateTime TIMESTAMP WITH TIME ZONE - OffsetDateTime
JDK 8版本的JDBC不包括INTERVAL之间的映射 类型和相应的310类.
JDK 8 version of JDBC does not include a mapping between the INTERVAL types and the corresponding 310 classes.
没有与任何其他310完全对应的SQL类型 类.结果，JDBC规范对所有其他类均保持沉默.
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.
我强烈建议JDBC开发人员使用新的310 类. java.util.Date，java.sql.Date， java.sql.Time和java.sql.Timestamp.你应该考虑一下 不推荐使用. 310个班级非常优越.
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.
道格拉斯
TL:DR;我们只是为您在数据库中存储时态数据的4种可能方式中的每一种选择了一种Java 8类型.
Finally, if you read through this thread it appears there is significant cultural pressure to keep standard APIs small and simple.
这篇关于为什么JPA不支持java.time.Instant?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
