ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / Проверка кол-ва изменённых строк при update/insert/delete
13 сообщений из 13, страница 1 из 1
Проверка кол-ва изменённых строк при update/insert/delete
    #39319575
Сурикат
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сурикат
Гость
Доброго времени суток.

Допустим, у нас есть какой-то DAO класс, работающий через JDBC. Нужно добавить метод, обновляющий поле записи по его id (id - уникальный). Вот первый вариант метода:


Код: java
1.
2.
3.
4.
public void upadateValue(String value, String id) {
	String sql = "UPDATE some_table SET table_value=? WHERE item_id = ?";
	jdbcTemplate.update(sql, value, id);
}



Вот второй вариант:

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
public Boolean upadateValue(String value, String id) {
	String sql = "UPDATE some_table SET table_value=? WHERE item_id = ?";
	int result = jdbcTemplate.update(sql, value, id);
	if(result != 1){ 
		return false;
	}		
	return true;
}



Во втором варианте, после обновления делается дополнительная проверка кол-ва изменённых записей. Если было изменено больше одной записи, либо ни одной, то возвращаем из метода значение false, указывающее, на ошибку. Иначе true, говорящее, что всё прошло как ожидалось.

Как частный случай, можно вместо булевого значения возвращать void, а в случае возникновения ошибки (result != 1) бросать какой-нить Exception. Такой подход выглядит надёжнее, т.к. тогда код, в котором вызывается этот метод, уже не сможет проигнорировать случай с ошибкой.

А теперь вопросы:

1. Нужно ли вообще делать подобную проверку (будь то возвращаемое значение или выбрасываемый эксэпшн)? С одной стороны, это даёт лишнюю уверенность, что код отработал верно. С другой стороны, это сильно смахивает на паранойю.

2. Если по предыдущему пункту ответ - проверку делать нужно, то писать подобную конструкцию с проверкой в каждом методе, выглядит как-то однообразно. Возможно для этого есть какие-то конкретные типичные решения или подходы?

3. В данном случае, по условию задачи обновление должно затрагивать только одну запись (по уникальному id). Но уникальность id описана в схеме БД, а проверка кол-ва изменений реализована в методе. Т.е. если вдруг в какой-то момент, изменится ожидаемое поведение (например станет допустимым иметь несколько записей с одним id), то этот метод со своей проверкой становится не актуальным. Т.е. такая проверка усложняет поддержку?

4. Возможно стоит делать проверку правильности обновления/удаления уровнем выше? Скажем, где-то в сервис-слое.

Дополнительные сомнения на счёт этого подхода возникают на фоне того, что в сети, практически нигде в примерах не встречал подобного. А это явный признак, что что-то делается не так.
...
Рейтинг: 0 / 0
03.10.2016, 13:02
| Ответить | Цитировать | Написать  
Проверка кол-ва изменённых строк при update/insert/delete
    #39319596
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Сурикатэто сильно смахивает на паранойю.
+1
Отлаживай правильный код в отладке при написании. А контролировать Оракле бессмысленно.
Банальный пример, твой код прошёл после соседа который удалил раньше эту запись. Или твой же код который разбит на куски.
Или технический код Очистить, который нажимаем "не важно, были ли там записи".
...
Рейтинг: 0 / 0
03.10.2016, 13:16
| Ответить | Цитировать | Написать  
Проверка кол-ва изменённых строк при update/insert/delete
    #39319612
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Сурикат1. Нужно ли вообще делать подобную проверку (будь то возвращаемое значение или выбрасываемый эксэпшн)? С одной стороны, это даёт лишнюю уверенность, что код отработал верно. С другой стороны, это сильно смахивает на паранойю.

А почему бы и нет. Лишние гарантии не помешают.

Сурикат2. Если по предыдущему пункту ответ - проверку делать нужно, то писать подобную конструкцию с проверкой в каждом методе, выглядит как-то однообразно. Возможно для этого есть какие-то конкретные типичные решения или подходы?

Проверил результат апдейта, сравнил с ожидаемым, если не совпало - выкинул исключение и откатил транзакцию. Вот и весь типовой подход. Использование true/false в данном случае попахивает.

Сурикат3. В данном случае, по условию задачи обновление должно затрагивать только одну запись (по уникальному id). Но уникальность id описана в схеме БД, а проверка кол-ва изменений реализована в методе. Т.е. если вдруг в какой-то момент, изменится ожидаемое поведение (например станет допустимым иметь несколько записей с одним id), то этот метод со своей проверкой становится не актуальным. Т.е. такая проверка усложняет поддержку?

Я ничего не понял. Есть метод, который решает конкретную задачу. Так чтобы поменять реализацию в БД и при этом не затронуть код бывает очень редко. В вашем случае значит это будет другой метод без уникальности.

Сурикат4. Возможно стоит делать проверку правильности обновления/удаления уровнем выше? Скажем, где-то в сервис-слое.

Не очень понятно что под этим подразумевается. Во-первых мы проверяем работу с БД. Поэтому это логика слоя работы с БД, а не логика реализации Transaction Script. Во-вторых, если у вас БД гарантирует ACID, то это одно. А если нет, то другое.

СурикатДополнительные сомнения на счёт этого подхода возникают на фоне того, что в сети, практически нигде в примерах не встречал подобного. А это явный признак, что что-то делается не так.
Для ORM по-моему это вполне заурядная проверка. Выхватывал несколько раз похожее исключение.
...
Рейтинг: 0 / 0
03.10.2016, 13:38
| Ответить | Цитировать | Написать  
Проверка кол-ва изменённых строк при update/insert/delete
    #39321295
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Арсеньев
Участник
Сурикат1. Нужно ли вообще делать подобную проверку
Тебе виднее. Надо тебе знать - есть такой id в базе или нет. (Самое простое из того, что проверяется).
Да и вообще - я бы возвращал int. Чтобы иметь возможность гибче устроить проверку (вдруг 0,1,2 вполне допустимые ответы, а 10 нет).
Сурикат2. Если по предыдущему пункту ответ - проверку делать нужно, то писать подобную конструкцию с проверкой в каждом методе, выглядит как-то однообразно.

Сразу видно, что Вы не адепт китайского стиля программирования. :)
СурикатТ.е. такая проверка усложняет поддержку?

Или облегчает - поменяют структуру базы, посыпятся ошибки - больше одного значения ключа, а не всякая белиберда мол списали 100 долларов, а зачислилось 200. И думай почему?
Сурикат
4. Возможно стоит делать проверку правильности обновления/удаления уровнем выше?

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


Все вышеизложенное глубокое IMHO
...
Рейтинг: 0 / 0
05.10.2016, 18:27
| Ответить | Цитировать | Написать  
Проверка кол-ва изменённых строк при update/insert/delete
    #39321340
Фотография fixxer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fixxer
Участник
А мне одному кажется, что мы тут пытаемся сделать работу за механизм ссылочной целостности в выбранной базе?

... some_table ( item_id foreign key ...
... item( item_id primary key ...

и все эти проверки теряют смысл.
...
Рейтинг: 0 / 0
05.10.2016, 19:22
| Ответить | Цитировать | Написать  
Проверка кол-ва изменённых строк при update/insert/delete
    #39321362
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
fixxer,
Не одному. Аффтар занимается ерундой.
IMHO).
...
Рейтинг: 0 / 0
05.10.2016, 19:42
| Ответить | Цитировать | Написать  
Проверка кол-ва изменённых строк при update/insert/delete
    #39321365
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
fixxer,

В примитивных ситуациях, конечно же, никто не заморачивается проверять результат всех апдейтов. Но в некоторых ситуациях бывает полезно. Вопрос в том какую именно проблему автор пытается этим решить.
...
Рейтинг: 0 / 0
05.10.2016, 19:44
| Ответить | Цитировать | Написать  
Проверка кол-ва изменённых строк при update/insert/delete
    #39321465
Сурикат
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сурикат
Гость
Petro123fixxer,
Не одному. Аффтар занимается ерундой.
IMHO).

Вполне возможно. Затем и спрашиваю, что бы познать дзен, исключить сомнения и перестать заниматься ерундой :)

BlazkowiczВопрос в том какую именно проблему автор пытается этим решить.

Ну вот простой пример: имеем какую-то сущность в БД. Нужно обновить поле, ну или удалить эту сущность. Т.е. мы точно знаем, что делаем UPDATE или DELETE для одного объекта. Причём мы уверены, что объект есть в БД (т.к., например, только что до этого мы его оттуда извлекли). Т.е. кол-во изменённых полей, должно быть равно 1.

Но, если вдруг оно равно 0. Или >1. Т.е. ожидали одно, а возвращённое значение говорит о другом. Этого, в общем-то не должно быть. По крайней мере, не должно быть значения >1, если мы меняем значение по уникальному ключу. Если вдруг такое случилось, то значит ключ этот уже не уникальный и нужно выяснить почему это так, и т.п. Либо если значение равно 0, то, можно сделать выводы о том, что мы пытаемся изменить объект который перестал существовать. Например его удалили, или ключ неверный или ещё что.

Но, всё это сильно похоже на паранойю. С другой стороны, лишняя перестраховка лишней не будет. Вот и любопытно мнение коллег, о том кто как сам пишет свой код. Ибо так сходу, в учебных и прочих примерах ничего подобного не встречал. Было бы сильно проще, если бы такие примеры были где-то сети, и было бы однозначно понятно. А так, в примерах одно, а в голове другое :)
...
Рейтинг: 0 / 0
05.10.2016, 23:35
| Ответить | Цитировать | Написать  
Проверка кол-ва изменённых строк при update/insert/delete
    #39321509
dimonz80
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimonz80
Гость
СурикатPetro123fixxer,
Не одному. Аффтар занимается ерундой.
IMHO).

Вполне возможно. Затем и спрашиваю, что бы познать дзен, исключить сомнения и перестать заниматься ерундой :)

BlazkowiczВопрос в том какую именно проблему автор пытается этим решить.

Ну вот простой пример: имеем какую-то сущность в БД. Нужно обновить поле, ну или удалить эту сущность. Т.е. мы точно знаем, что делаем UPDATE или DELETE для одного объекта. Причём мы уверены, что объект есть в БД (т.к., например, только что до этого мы его оттуда извлекли). Т.е. кол-во изменённых полей, должно быть равно 1.

Но, если вдруг оно равно 0. Или >1. Т.е. ожидали одно, а возвращённое значение говорит о другом. Этого, в общем-то не должно быть. По крайней мере, не должно быть значения >1, если мы меняем значение по уникальному ключу. Если вдруг такое случилось, то значит ключ этот уже не уникальный и нужно выяснить почему это так, и т.п. Либо если значение равно 0, то, можно сделать выводы о том, что мы пытаемся изменить объект который перестал существовать. Например его удалили, или ключ неверный или ещё что.

Но, всё это сильно похоже на паранойю. С другой стороны, лишняя перестраховка лишней не будет. Вот и любопытно мнение коллег, о том кто как сам пишет свой код. Ибо так сходу, в учебных и прочих примерах ничего подобного не встречал. Было бы сильно проще, если бы такие примеры были где-то сети, и было бы однозначно понятно. А так, в примерах одно, а в голове другое :)

Имеет смысл освежить свои знания про MVCC вообще, про уровни изоляции транзакций, в особенности READ COMMITTED и REPEATABLE READ в частности применительно к используемой СУБД, чтобы не задаваться вопросами "если вдруг оно равно 0. Или >1."

А так же про PK/FK и CONSTRAINT UNIQUE, чтобы не сомневаться, что "то значит ключ этот уже не уникальный" "или ключ неверный"
...
Рейтинг: 0 / 0
06.10.2016, 05:10
| Ответить | Цитировать | Написать  
Проверка кол-ва изменённых строк при update/insert/delete
    #39321511
dimonz80
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimonz80
Гость
dimonz80Сурикатпропущено...


Вполне возможно. Затем и спрашиваю, что бы познать дзен, исключить сомнения и перестать заниматься ерундой :)

пропущено...


Ну вот простой пример: имеем какую-то сущность в БД. Нужно обновить поле, ну или удалить эту сущность. Т.е. мы точно знаем, что делаем UPDATE или DELETE для одного объекта. Причём мы уверены, что объект есть в БД (т.к., например, только что до этого мы его оттуда извлекли). Т.е. кол-во изменённых полей, должно быть равно 1.

Но, если вдруг оно равно 0. Или >1. Т.е. ожидали одно, а возвращённое значение говорит о другом. Этого, в общем-то не должно быть. По крайней мере, не должно быть значения >1, если мы меняем значение по уникальному ключу. Если вдруг такое случилось, то значит ключ этот уже не уникальный и нужно выяснить почему это так, и т.п. Либо если значение равно 0, то, можно сделать выводы о том, что мы пытаемся изменить объект который перестал существовать. Например его удалили, или ключ неверный или ещё что.

Но, всё это сильно похоже на паранойю. С другой стороны, лишняя перестраховка лишней не будет. Вот и любопытно мнение коллег, о том кто как сам пишет свой код. Ибо так сходу, в учебных и прочих примерах ничего подобного не встречал. Было бы сильно проще, если бы такие примеры были где-то сети, и было бы однозначно понятно. А так, в примерах одно, а в голове другое :)

Имеет смысл освежить свои знания про MVCC вообще, про уровни изоляции транзакций, в особенности READ COMMITTED и REPEATABLE READ в частности применительно к используемой СУБД, чтобы не задаваться вопросами "если вдруг оно равно 0. Или >1."

А так же про PK/FK и CONSTRAINT UNIQUE, чтобы не сомневаться, что "то значит ключ этот уже не уникальный" "или ключ неверный"

И про пессимистические блокировки тоже на всякий случай
...
Рейтинг: 0 / 0
06.10.2016, 05:19
| Ответить | Цитировать | Написать  
Проверка кол-ва изменённых строк при update/insert/delete
    #39321531
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Tomin
Участник
Blazkowiczfixxer,

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

Вроде всё верно, мы обновляем строго одну запись. И никогда не может быть 0 или >1. Так что проверка "Verify.verify(updateCount == 1)" с одной стороны- лишняя.
С другой это:
1. Постоянный контроль, что мы не разломали код. При наличии интеграционных тестов- контроль у себя.
2. Документация . Т.е. читающий это видит, что мы меняем строго одну запись.

Т.е. если первая цель- это паранойя, то второе- это тот самый "самодокументируемый код", когда документация (verify) и код гарантироавно соответствуют друг другу. Жаль, что компилятор не вытаскивает check/verify в javadoc (тогда были бы мои любимые контракты).

А для нормального кода это нужно для оптимистичных блокировок
...
Рейтинг: 0 / 0
06.10.2016, 07:47
| Ответить | Цитировать | Написать  
Проверка кол-ва изменённых строк при update/insert/delete
    #39321554
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Сурикат,
Пиши бизнес логику.
Сабж к ней не относится.
Это не твоё дело.
Это либо в ОРМ либо в DAL.
В дельфи это в DAL.
В яп PL oracle это в самом языке.
В java нету т.к. тут более универсальный код и нижний слой понятия не имеет что там в базе и какая база.
Наплюй.
...
Рейтинг: 0 / 0
06.10.2016, 08:36
| Ответить | Цитировать | Написать  
Проверка кол-ва изменённых строк при update/insert/delete
    #39321658
mrWolf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mrWolf
Гость
Alexey TominВроде всё верно, мы обновляем строго одну запись. И никогда не может быть 0 или >1.
Если обновление по ключу, то > 1 никогда не будет, а вот 0 вполне себе может быть. Если запись при чтении не блокировалась, то к моменту обновления она вполне может быть удалена другим "пользователем".
...
Рейтинг: 0 / 0
06.10.2016, 10:20
| Ответить | Цитировать | Написать  
13 сообщений из 13, страница 1 из 1
Форумы / Java [игнор отключен] [закрыт для гостей] / Проверка кол-ва изменённых строк при update/insert/delete
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?desktop=1&fid=59&tid=2123643]:
 0ms
get settings:
 8ms
get forum list:
 18ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 143ms
get topic data:
 12ms
get forum data:
 2ms
get page messages:
 52ms
get tp. blocked users:
 1ms
others: 230ms
total:  472ms
созд. / загр.: 472ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]