спящий 4 и йода-время - PullRequest
Новая
       5

спящий 4 и йода-время

62 голосов
/ 23 января 2012

они счастливы в браке?

Я использую последнюю версию hibernate (4) и версию 1.3 с поддержкой joda-time hibernate , которую я также считаю текущей последней версией.

Кажется, что все работает нормально (столбцы даты созданы, как и ожидалось) при использовании аннотаций: 

@Column
@Type(type="org.joda.time.contrib.hibernate.PersistentLocalDate")
private LocalDate myDate;

Известны ли у них проблемы с совместным использованием этих версий?

Обновление Хорошо получается, что столбцы создаются, но не могут заполняться какими-либо данными:

Ошибка обработки обработчика; вложенным исключением является java.lang.AbstractMethodError: org.joda.time.contrib.hibernate.PersistentLocalDateTime.nullSafeSet

Они несовместимы, и я должен использовать usertype . См. Ответ ниже.

Ответы [ 2 ]

96 голосов
/ 24 января 2012

Отсутствие документации означает, что для меня может быть полезно записать шаги, необходимые для интеграции.Убедитесь, что ваши библиотеки обновлены.

Вам понадобится: [предполагается, что у вас уже есть hibernate4]

Последняя версия joda-time 

<dependency>
    <groupId>joda-time</groupId>
    <artifactId>joda-time</artifactId>
    <version>2.0</version>
</dependency>

и тип пользователяlib 

<dependency>
    <groupId>org.jadira.usertype</groupId>
    <artifactId>usertype.core</artifactId>
    <version>3.0.0.CR1</version>
</dependency>

Затем используйте следующие классы сущностей (необязательно должно быть LocalDateTime, может быть любой из доступных постоянных классов): 

import org.joda.time.LocalDateTime;

и для определения столбца:

@Column(name="updated", nullable = false)
@Type(type="org.jadira.usertype.dateandtime.joda.PersistentLocalDateTime")
private LocalDateTime updated;
29 голосов
/ 21 августа 2013

Я добавлю это как отдельный ответ, так как, по моему мнению, это важная информация для любого, кто обновляет Hibernate 4 и нуждается в переходе на использование постоянных временных типов jadira. Эта страница высоко оценена в результатах поиска Google для hibernate 4 и jodatime, поэтому я добавлю ее здесь. (Отдельное обсуждение этой проблемы см .: Joda time DateTime неправильно сохраняет в базе данных )

Если вы находитесь в часовом поясе, отличном от UTC, необходим важный элемент конфигурации, чтобы получить то же поведение, что и при использовании типа поддержки гибернации joda-time. По умолчанию временные типы jadira работают путем преобразования всех значений в часовой пояс UTC перед сохранением в базе данных и обратного преобразования в часовой пояс системы при загрузке значений из базы данных.

Я сгорел от этого после обновления, когда у меня было много временных меток с моим точным часовым поясом в базе данных (UTC + 1 (+2 в летнее время)). При загрузке после обновления до Hibernate 4 к значению в базе данных добавлялось 1 или 2 часа (в зависимости от того, была ли метка времени в летнее время), что означало, что все существующие метки времени были представлены ошибочно. Кроме того, новые значения меток времени были сохранены в базе данных с часовым поясом UTC, что привело к их правильному отображению в приложении, но неверно в базе данных. В общем, горячий беспорядок часовых поясов и временных меток.

Итак, чтобы получить то же поведение, что и с joda-times hibernate-support (сохраняемое время-дата соответствует часовому поясу рассматриваемого сервера, а метки времени в базе данных совпадают с тем, что загружается в приложения), следующие свойства должны быть добавлены в конфигурацию JPA / Hibernate (в моем случае, hibernate.properties): 

jadira.usertype.autoRegisterUserTypes=true
jadira.usertype.databaseZone=jvm
jadira.usertype.javaZone=jvm

Это обеспечит, чтобы временные метки в базе данных были того же часового пояса, что и приложение, что, в свою очередь, будет часовым поясом jvm (в большинстве случаев это часы сервера приложений).

Кроме того, насколько я понимаю, свойство autoRegisterUserTypes устраняет необходимость в аннотации @Type для выбора общих типов, в том числе типов Jodatime DateTime и LocalDate.

.
...