Запрос Select count (*) из JdbcTemplate возвращает другое значение, чем выполнение запроса из SQL терминала - PullRequest
Новая
       87

Запрос Select count (*) из JdbcTemplate возвращает другое значение, чем выполнение запроса из SQL терминала

0 голосов
/ 19 июня 2020

У меня есть этот простой запрос: 

sqlCount="  SELECT count(*)"+
            " FROM mytable "+
            " WHERE ID = ?"+
            " AND CANCEL_DATE IS NULL"+
            " AND LAST_NAME IS NOT NULL";




int count = jdbcTemplate.queryForObject(
                sqlCount, new Object[] { id }, Integer.class);

вызывается из Spring Boot.

Нет строк с переданным идентификатором (150). При запуске queryForObject появляется счетчик переменных как 1, тогда как при выполнении того же запроса от SQL Developer он появляется как 0 !!

Что здесь происходит? Что мне не хватает?

1 Ответ

1 голос
/ 22 июня 2020

Возможные причины

a) вы подсчитываете количество возвращенных строк (это ОДНА), а не значение внутри этой возвращаемой строки

b) у вас есть незафиксированная транзакция вставки , что означает SQL Разработчик не может его увидеть

Но в любом случае ваш комментарий, в котором вы сказали: «После того, как я сделаю эту проверку, я продолжу вставлять строки», тогда ваш метод все равно необходимо пересмотреть.

Концепция: сначала запросить наличие, а затем вставить, если нет, в основном ошибочна, если только она не поддерживается через соответствующее ограничение базы данных или аналогичный режим блокировки. Потому что в противном случае вы попадете в ситуацию:

Сессия 1 - проверка на наличие, ничего не найдено, все в порядке, делаем вставку ... Сессия 2 - проверка на наличие, ничего не найдено, мы ' re ОК, сделайте вставку ... Сессия 1 - фиксация Сессия 2 - фиксация

и вуаля ... у вас есть несколько вхождений значения, когда вы ожидали только 1.

Если вы действительно ли определено соответствующее уникальное ограничение / индекс, тогда вам вообще не нужно выполнять проверку счетчика, потому что вставка либо сработает, либо будет отклонена как дубликат. Меньше кода и нет проблем с повреждением данных.

...