При передаче в запрос текущей даты (new Date()) в Tomcat, дата передается с текущими часами, минутами, секундами (т.е. имеет вид: 2019-02-22 10:11:14.635)
При передаче в запрос текущей даты (new Date()) в uberJar, дата передается с нулями в качестве часов, минут, секунд (т.е. имеет вид: 2019-02-22 00:00:00.0)
Можете подсказать почему дата передается по разному?
Добрый день,
Дело не в контейнере, так как он никак не участвует в доставке дат до базы данных - вы ведь имеете ввиду сохранение Date в БД ?
У вас в двух этих случаях либо разные JDBC драйверы, либо разная строка подключения к БД. Либо разные настройки сервера БД.
Как пример из моей практики - в mssql добавление “sendTimeAsDatetime=false;” в connection URL влияет на точность передачи дат.
Я имела ввиду запрос на начитку данных из БД.
Был запрос:
“select e from ot$OperatingTable e where e.code=:code and e.tableState=:state and " +
" ((e.beginDate is null) or (@dateBefor(e.beginDate <= :date))) and " +
" ((e.endDate is null) or (@dateAfter(e.endDate, :date))) " +
" order by e.beginDate desc”
В БД в поле beginDate - дата хранится без времени. А в параметризированный параметр “:date” передается значение new Date(). И вот именно этот параметр передается по разному в Tomcat и uberJar.
Драйвер JDBC точно один и тот же, подключение к БД тоже одно.
Если вы скопировали запрос прямо из кода, то у вас там опечатка в названии макроса.
По-любому должна быть какая-то разница, или в коде, или в system properties при запуске сервера, или в local app properties.
Обрезанием времени при использовании @dateBefore / @dateAfter занимаются макросы com.haulmont.cuba.core.sys.querymacro.DateBeforeMacroHandler и com.haulmont.cuba.core.sys.querymacro.DateAfterMacroHandler
Могу только посоветовать поставить там точку останова и посмотреть, что там происходит.
Или включить логгирование sql через категорию “eclipselink.sql”.
Нет, я как раз dateBefor руками дописала, т.к. мы уже у себя убрали использование этого макроса.
В коде разницы нет, логирование sql через категорию “eclipselink.sql” как раз применили. Разницу именно там и обнаружили.
Запрос, который видим в логе Tomcat:
SELECT ID, DTYPE, ARRAY_VAR_CODE, BEGIN_DATE, CODE, DELETE_TS, DELETED_BY, DESCRIPTION, END_DATE, IS_AGGREGATE, IS_CALCULATE, IS_WORK_TO_FIRST_ALG, LAST_VALIDATING_RESULT, NAME, TABLE_STATE, VERSION FROM OT_OPERATING_TABLE WHERE (((((CODE = ?) AND (TABLE_STATE = ?)) AND ((BEGIN_DATE IS NULL) OR (BEGIN_DATE <= ?))) AND ((END_DATE IS NULL) OR (END_DATE >= ?))) AND ((DELETE_TS IS NULL) AND (DTYPE = ?))) ORDER BY BEGIN_DATE DESC
bind => [POLIGON_64_TABLE, 60, 2019-02-26 18:50:41.406, 2019-02-26 18:50:41.406, kvprod$ExtOperatingTable]
Запрос, который видим в uberJar:
SELECT ID, DTYPE, ARRAY_VAR_CODE, BEGIN_DATE, CODE, DELETE_TS, DELETED_BY, DESCRIPTION, END_DATE, IS_AGGREGATE, IS_CALCULATE, IS_WORK_TO_FIRST_ALG, LAST_VALIDATING_RESULT, NAME, TABLE_STATE, VERSION FROM OT_OPERATING_TABLE WHERE (((((CODE = ?) AND (TABLE_STATE = ?)) AND ((BEGIN_DATE IS NULL) OR (BEGIN_DATE <= ?))) AND ((END_DATE IS NULL) OR (END_DATE >= ?))) AND ((DELETE_TS IS NULL) AND (DTYPE = ?))) ORDER BY BEGIN_DATE DESC
bind => [POLIGON_64_TABLE, 60, 2019-02-26 00:00:00.0, 2019-02-26 00:00:00.0, kvprod$ExtOperatingTable]
Разница в передаваемых бинд переменных, даже когда уже не используем макрос.
Вот и хотелось понять, почему так…