спящий режим 4 и joda-время

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

Я использую последнюю версию 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. См. ответ ниже.


person NimChimpsky    schedule 23.01.2012    source источник
comment
Вы только что сказали нам, что они действительно работали вместе, не так ли?   -  person skaffman    schedule 23.01.2012
comment
@skaffman Я не тестировал ничего, кроме создания столбцов ... насколько я понял, предыдущие версии (joda-time lib) нужно было перекомпилировать с более новой версией hibernate. Это забило тревогу - отсюда и вопрос...   -  person NimChimpsky    schedule 23.01.2012
comment
Они не счастливы в браке, у спящего режима другие отношения... и джода.. :/.. Ей больно   -  person nobalG    schedule 19.01.2015
comment
Также будьте осторожны при импорте LocalDate, потому что теперь он также доступен в Java 8.   -  person jgr    schedule 25.09.2015


Ответы (2)


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

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

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

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

и библиотека пользовательских типов

<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;
person NimChimpsky    schedule 24.01.2012
comment
Откуда мы знаем, какой тип он соответствует в выбранной нами базе данных? - person benstpierre; 31.05.2012
comment
Верно, так использовать автогенерацию таблиц и смотреть на результат? - person benstpierre; 31.05.2012
comment
да, я бы так и сделал - копаться в документации по спящему режиму довольно сложно - person NimChimpsky; 31.05.2012
comment
На случай, если у кого-то возникнет та же проблема: я только что споткнулся о новый функция автоматической регистрации, которая регистрирует множество типов JodaTime, но не LocalDateTime. Указание типа, как указано выше, по-прежнему остается единственным вариантом. - person Stefan Haberl; 31.07.2012
comment
Стефан, вы должны обнаружить, что LocalDateTime также зарегистрирован в последней версии (3.0.0.GA). - person Chris Pheby; 25.10.2012
comment
Спасибо! Это успешно работает с Hibernate 4.3.8 и Joda Time 2.7 и Jadira 3.2.0GA. - person Gondy; 24.02.2015
comment
Просто комментарий на сегодня. Текущая версия org.jadira.usertype:usertype.core7.0.0.CR1. - person gaoagong; 24.01.2020

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

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

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

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

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

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

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

person Tobb    schedule 21.08.2013
comment
Поскольку вы решили свою проблему, и она не была напрямую связана с этим вопросом, я удалю свои комментарии и отмечу ваши для удаления, поэтому мы сохраняем раздел комментариев чистым и точным. - person Tobb; 21.03.2014
comment
Просто вопрос в сторону: почему бы не хранить каждую метку времени в формате UTC? Что, если сервер переместится в другой часовой пояс? Имхо, было бы лучше хранить все временные метки в формате UTC и позволить клиенту решать, в каком часовом поясе он находится. - person Stefan Falk; 19.08.2015
comment
В общем я бы согласился. Однако в моем случае не было никаких шансов, что сервер будет перемещен в другой часовой пояс. Кроме того, проблема здесь в том, что поведение по умолчанию меняется, в моем случае без моего ведома. Поэтому, когда вы не знаете, что это происходит, вы не можете перенести свои данные и в итоге получите набор временных меток с разными часовыми поясами, что, конечно, нехорошо. Но, если это имеет смысл для вашего проекта, вы можете пропустить приведенную здесь настройку и вместо этого перенести базу данных. Одна вещь, которая является негативной при переходе на все UTC, заключается в том, что отчеты SQL становятся либо сложными, либо неправильными. - person Tobb; 20.08.2015
comment
Размышляя об этом, я нахожу что-то принципиально неправильное в хранении дат в другом часовом поясе, чем использует сервер. В SQLServer даты и время хранятся как количество дней с 1900-01-01, а также количество тактов часов с полуночи. При преобразовании дат в другой часовой пояс вы также меняете внутреннее представление даты, что на самом деле делает его неточным. Не знаю, действительно ли это проблема на практике, но я знаю, что есть некоторые программы, которые используют внутреннее представление даты для вычисления правильного смещения часового пояса. - person Tobb; 20.08.2015