Почему этот результат Anorm представляет собой пустой список? (Воспроизвести 2.1.0)

Нуб Scala здесь; для жизни я не могу понять, почему я не получаю результат для этого вызова Anorm SQL. Когда я запускаю вывод отладки SQL, он возвращает результат просто отлично, но при запуске кода я получаю пустой список().

Есть ли проблема с моим RowParser? Почему я вижу хороший SQL в выводе отладки, но он не собирается моим значением result?

Я что-то упустил в своем SQL .as(), чтобы правильно сопоставить строки результатов с парсером? Когда я удаляю последнюю строку result, мое значение result оценивается как единица, что определенно подозрительно.

// Case class - SQL results rows go into List of these
case class PerformanceData(
    date: String, 
    kwh: String
)

// RowParser
val perfData = {
    get[String]("reading_date") ~ get[String]("kwh") map{ 
        case reading_date~kwh => PerformanceData(reading_date, kwh) 
    }
}

// SQL Call - function ret type is Seq[PerformanceData]
DB.withConnection("performance") { implicit connection => 

    val result: Seq[PerformanceData] = SQL(
    """
        SELECT CONCAT(reading_date) AS reading_date,
           CONCAT(SUM(reading)) AS kwh
        FROM perf
        WHERE reading_date >= DATE_SUB(NOW(), INTERVAL 45 DAY)
        AND sfoid IN ({sf_account_ids})
        GROUP BY reading_date
        ORDER BY reading_date DESC
        LIMIT 30
    """
    ).on(
        'sf_account_ids -> getSQLInValues(SFAccountIDs)
    ).as(
        User.perfData *
    )

//  Logger.debug(result.toString) -> EMPTY LIST!??
    result // Why is this necessary to return proper type?

}

person notbrain    schedule 10.04.2013    source источник
comment
См. этот мой ответ относительно пунктов IN в Anorm.   -  person maba    schedule 10.04.2013


Ответы (2)


К сожалению, вам нужно использовать не переменные привязки, а замену строкового значения для предложения IN.

см. также: Предложение In в стандарте?

Редактировать: я имел в виду, что sf_account_ids будет переменной с одной привязкой. Возможно, ожидается sfoid IN (?, ?, ?), но оператор будет sfoid IN (?).

person Kazuhiro Sera    schedule 10.04.2013
comment
это не моя проблема. SQL отображается нормально, вызов для получения списка идентификаторов предотвращает неверные значения - person notbrain; 10.04.2013
comment
или вы говорите, что SQL не будет работать, если я просто создам SQL как строку, используя mkstring? отладочный SQL отлично работает вручную. - person notbrain; 10.04.2013
comment
Я имел в виду, что sf_account_ids будет одиночной переменной привязки. Возможно, ожидается sfoid IN (?, ?, ?), но оператор будет sfoid IN (?). - person Kazuhiro Sera; 10.04.2013
comment
Можете ли вы отредактировать свой ответ, чтобы я мог проголосовать и отметить его как ответ? Я ошибся в том, что регистратор выдавал совершенно правильный SQL, но молча не мог отправить запрос и связать его. Исправление заключалось в том, чтобы заранее создать SQL-запрос и вообще не использовать привязку. Это также маскировало проблему с моим предположением, что CONCAT() также позволит мне привязываться к строкам в RowParser. - person notbrain; 10.04.2013

Для первого вопроса я предлагаю вам проверить свое case заявление в perDataи убедиться, что оно точное. Функция getSQLInValues(...) также может быть причиной.

На вопрос, почему вам нужен последний result, и это потому, что scala использует последний оператор в закрытии, чтобы вывести тип возвращаемого значения, если он не определен явно. Таким образом, val result = SQ(...), будучи присваиванием, вернет Unit

Чтобы избежать этого, вы можете сделать что-то вроде:

DB.withConnection("performance") { implicit connection =>
  SQL(...).on(...).as(...)
}

Не назначая возврат из SQL, он используется для вывода типа.

person korefn    schedule 10.04.2013