Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Java EE (J2EE) и Spring > Неотмеченные checkbox'ы в форме


Автор: batigoal 31.5.2005, 15:05
Ситуация:

есть таблица с двумя десятками записей. В ней два столбца: строка и число (0 или 1).
На ее основе формируется страница с двумя десятками флажков. Пользователь вносит изменения, нажимает submit. Но ведь отправляться будут только отмеченные элементы.

Вопрос: как лучше вносить изменения в базу? Вижу два варианта обработки запроса:
1. Записать 0 во все строки, потом перезаписать отмеченные на 1.
2. С помощью JS или hidden-полей передавать имена неотмеченных флажков в запросе.

Автор: maximb 31.5.2005, 15:12
Цитата(Lamer @ 31.5.2005, 15:05)
есть таблица с двумя десятками записей. В неесть страница с двумя десятками флажков


и наверное неотмеченные чекбоксы не приезжают в посте ? smile

а если сперва записать все отмеченные с 1
а потом все оставшиеся с 0

Автор: batigoal 31.5.2005, 15:19
Это у меня комп колбасит, в три захода писал. Но ты и так ситуацию понял верно smile

Вопрос, собсно, в том, как лучше?

Автор: Dancer 31.5.2005, 15:31
А что если в сессию положить число, если твоя табличка состоит только лишь из 20 строк, то 32 бита должно хватить вполне. Битовая маска этого числа будет являтся отображением твоих 0/1 в базе.

Автор: batigoal 31.5.2005, 15:40
Цитата(Dancer @ 31.5.2005, 16:31)
А что если в сессию положить число, если твоя табличка состоит только лишь из 20 строк, то 32 бита должно хватить вполне. Битовая маска этого числа будет являтся отображением твоих 0/1 в базе.

Но ведь положить-то его можно только при серверной обработке. Юзер из своей странички сделать этого не сможет.

Автор: polosatij 31.5.2005, 16:02
Цитата(Lamer @ 31.5.2005, 15:05)
1. Записать 0 во все строки, потом перезаписать отмеченные на 1.


я бы так сделал + смотрел на "<" и ">" с приходящих значений // секьюрити.

зачем ещё ява скрипт городить smile

Автор: batigoal 31.5.2005, 16:05
Цитата(polosatij @ 31.5.2005, 17:02)
смотрел на "<" и ">" с приходящих значений

Не понял. Что ты имеешь в виду?

Автор: maximb 31.5.2005, 16:06
1. перед тем как сформировать страничку кладешь в сессию все данные по которым формируются чекбоксы
2. генеришь пользователю страничку с чекбоксами
3. пользователь отмечает интересующие его чекбоксы
4. пользователь жмет сабмит
5. все отмеченные чек боксы приезжают на сервер
6. пишешь в базу все данны которые соответствуют отмеченным чекбоксам с "1"
7. те данные для которых не было найдено соответствующего чекбокса в реквесте пишешь в ДБ с "0"

Автор: batigoal 31.5.2005, 16:16
Похоже, равноценные варианты получаются (с точки зрения количества обращений к базе). Наверное, все же возьму
Цитата
Записать 0 во все строки, потом перезаписать отмеченные на 1.

Вроде как покороче будет.

Автор: maximb 31.5.2005, 16:20
Ну если "0" во все строки будет вставляться в одном запросе к ДБ тогда это лучше,
но если все выполняется отдельными, небольшими запросами тогда надо еще подумать
какой вариант более подходит

Автор: batigoal 31.5.2005, 16:23
Буду делать одним запросом с кучей "OR".

Автор: maximb 31.5.2005, 16:30
Цитата(Lamer @ 31.5.2005, 16:23)
Буду делать одним запросом с кучей "OR".

тогда да smile

Автор: 3,14 31.5.2005, 18:16
Наверняка можно подменить OutputStream к-ым пользуется драйвер для обращение к БД на BufferedOutputStream, посмотрел бы сам да времени сейчас в обрез, в этом случае думаю что все INSERT запросы отослались бы за одно образение к БД.

Автор: batigoal 31.5.2005, 18:24
Да я и так все делаю в один UPDATE, так что не стоит заморачиваться.

Автор: Stampede 31.5.2005, 18:38
Цитата(Lamer @ 31.5.2005, 16:23)
Буду делать одним запросом с кучей "OR".


Пара замечанией: если будешь делать одним запросом, можно вместо OR воспользоваться констркуцией where <column-name> in (value1, value2, ... , valueN). Никакой особой разницы, просто код чуть проще.

Но не будет особой беды и вызвать 20 апдейтов, если сделать через PreparedStatement - вопрос миллисекунд. Зато код будет чище. Просто динамическая генерация SQL - это такое средство, к которому лучше прибегать в самом последнем случае.

ЗЫ. А у тебя где обработка сабмита происходит? В сервлете?

Автор: batigoal 31.5.2005, 18:40
Цитата(Stampede @ 31.5.2005, 19:38)
если будешь делать одним запросом, можно вместо OR воспользоваться констркуцией where <column-name> in (value1, value2, ... , valueN).

Угу, воспользуюсь.

Цитата(Stampede @ 31.5.2005, 19:38)
Но не будет особой беды и вызвать 20 апдейтов, если сделать через PreparedStatement - вопрос миллисекунд.

Думаю, нет смысла - не часто будет использоваться.

Цитата(Stampede @ 31.5.2005, 19:38)
А у тебя где обработка сабмита происходит? В сервлете?

В кастом теге.

Автор: Stampede 31.5.2005, 19:01
Цитата(Lamer @ 31.5.2005, 18:40)
Цитата (Stampede @ 31.5.2005, 19:38)
Но не будет особой беды и вызвать 20 апдейтов, если сделать через PreparedStatement - вопрос миллисекунд.

Думаю, нет смысла - не часто будет использоваться.


Если не часто будет использоваться, тогда разница в миллисекунды вообще никакого рояля не играет. А что касается PreparedStatement, то его смысл в данном случае не в том, чтобы сохранять откомпиленный запрос между вызовами страницы (поскольку он в кэше ДБ сервера до следующего вызова, вероятно, просто не доживет), а в том, чтобы:

а) сохранять его между отдельными апдейтами в процессе обработки одной страницы, и

б) избежать генерации SQL кода.

То есть если ты напишешь примерно такую функцию, то она будет мослать очень быстро:

Код

private static final String updFlag = "UPDATE FLAGS SET FLAG_ON=1 WHERE FLAG_NAME=?";

private void updateFlag(String flagName, Connection con) throws SQLException
{
  PreparedStatement pstm = con.prepareStatement(updFlag);
  pstm.setString(1, flagName);
  pstm.executeUpdate();
  pstm.close();
}


Впрочем, дело вкуса. Вернее, не столько вкуса, сколько предпочтений кодирования, которые только отчасти обусловлены вкусом, а от другой части - опытом наступания на грабли и набитыми шишками smile

Автор: Stampede 31.5.2005, 20:26
Цитата(Stampede @ 31.5.2005, 18:38)
Просто динамическая генерация SQL - это такое средство, к которому лучше прибегать в самом последнем случае.


Цитата(Stampede @ 31.5.2005, 19:01)
Впрочем, дело вкуса. Вернее, не столько вкуса, сколько предпочтений кодирования, которые только отчасти обусловлены вкусом, а от другой части - опытом наступания на грабли и набитыми шишками


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

Самое неприятное, что такой случай может наступить когда угодно: сегодня, завтра, через месяц, через год... короче, никогда не знаешь, где рванет smile

Я не говорю, что SQL совсем не надо генерировать - иногда, действительно, это бывает более простым, а подчас и единственно возможным решением. Но каждый раз, когда это делаешь, нужно относиться к этому как к мине замедленного действия и _очень_ внимательно анализировать (и тестировать) на предмет специальных ситуаций (null значений, спецсиволов в значениях строк, пустых списков и прочей белиберды).

А еще лучше - по возможности вообще не связываться, целее будешь smile

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)