2015-01-05 2 views
0

Мы используем HyperSql как наш блок тестовой базы данных, мы имеем HQL (мы используем спящий режим 3.3.1), как этотЧто изменилось для Timestamp в HyperSql 2.3 по сравнению с HyperSql 2.0?

select count(*) from TestTable where create_date <= current_timestamp; 

тип create_date является отметка времени. Код отлично работает для HyperSql 2.0, но не для HyperSql 2.3.

Кто-нибудь знает, что изменилось для реализации метки времени от 2.0 до 2.3? Это какое-то изменение, связанное с часовым поясом? Я проверил Changenotes HyperSql, но ничего не нашел.

Update Вот подробности: HyperSql, используемые как в памяти БД для модульного тестирования. Схема автоматически создается на основе аннотированного класса. В столбце create_date отображается, как показано ниже:

@Column(name = "create_date", nullable = false) 
    public Timestamp getCreateDate() { 
    return createDate; 
} 

тестирования, 1) опорожнить базу данных, 2) вызвать один метод, который должен вставить запись в базе данных 3) проверка БД содержит запись, которая имеет запись с create_date < = current_timestamp.

Если есть поле только спящий режим, то выход, как этот

createDate=2015-01-06 13:06:42.132 
current_timestamps=2015-01-06 13:06:42.4 

он прекрасно работает с HyperSQL 2.0, но с 2.3, ноль записей возвращается. Я думаю, что это проблема с часовым поясом, но из печатной продукции я не видел информацию о часовом поясе. Отображаемое время было местным. Часовой пояс моего хозяина - CST (UTC + 8).

Любое предложение о том, как его отладить?

+0

Что именно означает «не работает»? Пожалуйста, покажите некоторые примеры данных ('create table ...', 'insert into ...', 'select ...'), который воспроизводит вашу проблему. –

+0

Обновлено с подробной информацией. Я думаю, что это касается Timezone, но мне интересно, как его отладить. – Dongqing

ответ

1

Трудно сказать. Hibernate 3.3.1 является слишком старым и не полностью совместимым с HSQLDB 2.x.

Это также может быть проблема с часовым поясом. Тип TIMESTAMP по умолчанию не имеет часового пояса, но CURRENT_TIMESTAMP имеет неявный часовой пояс. LOCALTIMESTAMP не имеет часового пояса и должен использоваться по сравнению с обычной колонкой TIMESTAMP.

Обновление: Это проверено и признано регрессией, когда одна метка времени и другая без часового пояса. Он был исправлен и привязан к SVN для следующей версии 2.3.3.

+0

Спасибо, я попробую – Dongqing

Смежные вопросы