Оператор myBatis Callable — проблема с датой Java

Я использовал mybatis-3.1.1, и в следующем коде не было проблем.

Реализация ДАО

    @Override
public ItunesPriorityReportDates getWeeklyPriorityDates(Date reportRunDate){

    ItunesPriorityReportDates itunesPriorityReportDates = new ItunesPriorityReportDates();
    Map<String,Object> weeklyPriorityDatesParamMap = new HashMap<>();

    weeklyPriorityDatesParamMap.put("reportRunDate", reportRunDate);

    log.debug("Report Run Date : " + reportRunDate);

    this.getItunesAnalysisMapper().getWeeklyPriorityDates(weeklyPriorityDatesParamMap);

    itunesPriorityReportDates.setAriaWeekStartDate((Date)weeklyPriorityDatesParamMap.get("ariaWeekStartDate"));
    itunesPriorityReportDates.setAriaWeekEndDate((Date)weeklyPriorityDatesParamMap.get("ariaWeekEndDate"));
    itunesPriorityReportDates.setitunesAccountPeriodStartDate((Date)weeklyPriorityDatesParamMap.get("itunesAccountPeriodStartDate"));
    itunesPriorityReportDates.setitunesAccountPeriodEndDate((Date)weeklyPriorityDatesParamMap.get("itunesAccountPeriodEndDate"));

    return itunesPriorityReportDates;

}

Картограф

    public ItunesPriorityReportDates getWeeklyPriorityDates(Map<String,Object> weeklyPriorityDatesParamMap);

XML-картограф.

    <select id="getWeeklyPriorityDates" parameterType="java.util.HashMap" statementType="CALLABLE">
    {CALL external_reporting.itunes_sales.get_weekly_priority_dates(#{reportRunDate                 mode=IN, jdbcType=DATE},
                                                                    #{ariaWeekStartDate             mode=OUT, jdbcType=DATE},
                                                                    #{ariaWeekEndDate               mode=OUT, jdbcType=DATE},
                                                                    #{itunesAccountPeriodStartDate  mode=OUT, jdbcType=DATE},
                                                                    #{itunesAccountPeriodEndDate    mode=OUT, jdbcType=DATE}
                                                                    )
    }
</select>

После обновления до mybatis-3.2.5 теперь он передает null как DATE в процедуру Oracle.

Не могли бы вы помочь мне с этим? Не уверен, что мне нужно обновить свой XML-картограф и включить что-то, чтобы он правильно анализировался.

Я использую java.util.Date в java.

Спасибо, Чираг.


person Chirag Jhaveri    schedule 20.02.2014    source источник
comment
Вы пробовали jdbcType=TIMESTAMP? Это то, что я использую.   -  person David Stanley    schedule 21.02.2014
comment
Пытался. Разработчик myBatis помог мне, и они решили эту проблему. Это было незадокументированное изменение, которое произошло около года назад. Они перестали использовать пробел в качестве разделителя. У меня не было запятой между именем свойства и РЕЖИМОМ. #{reportRunDate mode=IN, просто добавил запятую после reportRunDate и работал как часы. То же самое добавить запятую после каждого имени свойства, и это сработало.   -  person Chirag Jhaveri    schedule 24.02.2014


Ответы (1)


Получил решение от Эдуардо Макаррона (разработчик myBatis)

Я понял. Это интересное открытие. Посмотрите на выражение, которое вы написали.

{режим reportRunDate=IN, jdbcType=DATE},

Запятая не разделяет имя свойства и режим!

Происходит то, что 3.0 и 3.1 допускали использование пробела в качестве разделителя, хотя это было недокументировано, не проверено и, по крайней мере, в моем случае неизвестно :)

Код синтаксического анализа 3.2 был улучшен, и теперь он поддерживает четко определенную грамматику:

  • Анализатор выражения встроенного параметра. Поддерживаемая грамматика (упрощенная):
  • встроенный параметр = (имя_свойства | выражение) атрибуты oldJdbcType
  • propertyName = /путь навигации по свойствам языка выражений/
  • выражение = '(' /выражение языка выражений/ ')'
  • oldJdbcType = ':' /любой допустимый тип jdbc/
  • атрибуты = (',' атрибут)*
  • атрибут = имя '=' значение

И пробел не является допустимым разделителем (поэтому свойства на самом деле могут называться «датой ввода»).

Это изменение было нежелательным, но оно было введено в версии 3.2 год назад, поэтому я боюсь, что мы не сможем вернуться назад.

Я надеюсь, что вы просто пропустили запятую, и это было не намеренно. Извиняюсь!

person Chirag Jhaveri    schedule 23.02.2014