it-swarm.com.ru

Почему JPA не поддерживает Java.time.Instant?

Я думаю, что Java.time.Instant - лучший выбор для сохранения даты в БД: это наиболее вероятная ОТМЕТКА ВРЕМЕНИ, и вы не зависите от часового пояса, это всего лишь момент времени. 

JPA поддерживает LocalDate, LocalTime, LocalDateTime и т.д., Но не Instant. Конечно, вы можете использовать либо AttributeConverter, либо некоторые библиотеки, такие как Jadira но почему это не поддерживается из коробки?

6
Filosssof

Я попробую это снова. Существует некоторое обсуждение в вопрос . Последняя дискуссия выглядит так:

mkarg сказал: Хотя это абсолютно правильно, технический ответ немного сложнее: что является последним предикатом, который делает тип данных право на включение в набор обязательных сопоставлений типов?

Можно сказать, что предикат является «существенным» или «общеупотребительным Пользой», но кто определяет, что такое «существенное» или «общее использование»? Смотрите, для некоторые приложения, поддержка Java.awt.Image и Java.net.URL может быть гораздо более важным, чем поддержка LocalDate или ZonedDateTime. На С другой стороны, другие приложения могут быть заполнены LocalDate, но никогда не использует Instant. Так где именно сделать разрез? Это становится особенно сложный, если взглянуть на огромное количество найденных типов в JRE, и очевидно, что где-то должен быть разрез. Четное JavaFX, входящий в комплект JRE, по-прежнему не поддерживает Instant в v8, так зачем же JPA? И, глядя на текущий прогресс Проект Jigsaw, возможно, предикат квалификации может быть просто ответил "все типы в конкретном модуле головоломки"?

В любом случае, это не мое решение. Я поддерживаю вашу просьбу и Хотелось бы видеть поддержку для всех времен Java Time API, особенно для Instant и Duration, и ваш запрос имеет заметное значение как я узнал, сторонники любят чемпиона Java Аруна Гупу. относительно недавно. Но я сомневаюсь, что окончательный ответ будет так же просто удовлетворительным как мы хотели бы иметь это.

Возможно, было бы лучше просто установить другую JSR, например «Общие Преобразования типов данных для платформы Java», которая предоставляет гораздо больше отображения, а не только дата и время, но также не будут привязаны к JPA но также может использоваться JAXB, JAX-RS и, возможно, более API, что дело в чем проблема превращения "в"? Имея такой автомобиль действительно уменьшит шаблон.

TL-DR; Есть много типов. Мы должны были провести черту где-то.

Существует новая проблема для добавления в будущую версию JPA.

Еще один интересный фрагмент анализа, который я нашел в ветке by Дуглас Сурбер (работает на JDBC):

Версия JDBC для JDK 8 включает поддержку большинства типов SQL что соответствует 310 классам.

ДАТА - LocalDate ВРЕМЯ - LocalTime TIMESTAMP с зоной вне времени - LocalDateTime TIMESTAMP с зоной времени - OffsetDateTime

Версия JDBC для JDK 8 не включает отображение между ИНТЕРВАЛОМ типы и соответствующие 310 классов.

Не существует типа SQL, который точно соответствует любому другому 310 классы. В результате спецификация JDBC молчит для всех других классов.

Я настоятельно рекомендую разработчикам JDBC использовать новую версию 310 классы. Есть проблемы с Java.util.Date, Java.sql.Date, Java.sql.Time и Java.sql.Timestamp. Вы должны рассмотреть их осуждается. 310 классов значительно выше.

Дуглас

TL: DR; Мы просто выбрали один тип Java 8 для каждого из 4 возможных способов хранения временных данных в базе данных.

Наконец, если вы прочитаете эту ветку окажется, что существует значительное культурное давление, чтобы стандартные API были небольшими и простыми.

7
Pace

Это не проблема JPA, а проблема JDBC. 

JDBC поддерживает Date, Timestamp, LocalDate, LocalTime и LocalDateTime, но НЕ Мгновенно .

Это не проблема Java, а проблема SQL, в результате чего то, что хранится в базе данных, является конструкцией год-месяц-день-час-минута-секунда.

Подумайте о функциях SQL: YEAR () MONTH () И т.д ...

Эти функции нельзя применять к простым миллисекодам с 1970 года. Им требуется конструкция LocalDateTime для выполнения этих функций.

0
klonq