Возможность возврата состояния контроля ОТК в "не контролировалось"

[alx]

В БД изделий АДС в коде otk.php я обнаружил такой фрагмент:

if ($_POST['status'] == 'fail')
    $query = "UPDATE products set `otk` = ?, `mismatch` = 'yes' where `uid` = ?";
else if ($_POST['status'] == 'ok')
    $query = "UPDATE products set `otk` = ?, `mismatch` = 'no' where `uid` = ?";
else
    $query = "UPDATE products set `otk` = ? where `uid` = ?";

В чем смысл наличия третьей ветки условия (любой другой статус кроме "успешно" и "неуспешно")?

Единственно возможный статус кроме "успешно" и "неуспешно" - это "не контролировалось". Логика подсказывает, что изделие может перейти из состояния "не контролировалось" как в состояние "успешно", так и в состояние "неуспешно". Также можно представить, что изделие переходит из состояния "успешно" в "неуспешно" и наоборот (в результате повторного контроля ОТК). Но если изделие уже когда-то проходило контроль ОТК (то есть имеет статус "успешно" или "неуспешно"), то оно уже никак не может вернуться в состояние "не контролировалось" (так как это будет неправдой):

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

[Denis_N]

Спасибо, Алексей. Исправлю

[Denis_N]

In 153/base:

Удалена ненужная строка из и-а "ОТК" по тикету Алексея
closes #1060

[alx]

Replying to Denis_N:

Удалена ненужная строка из и-а "ОТК" по тикету Алексея

Хм... Вообще-то в описании тикета предлагалось не удалить, а изменить третью ветку условия, чтобы при получении отличного от "успешно" и "неуспешно" статуса система ругалась (выдавала ошибку) вместо записи в БД.

А что теперь произойдет теперь в описанном случае? Будет начата транзакция, добавлена запись в историю, после чего будет выполнено prepare() с аргументом undefined, что вызовет исключение (и да, php сругается, так что формально предложение тикета выполнено, хотя когда я написал "ругаться", я не совсем это имел в виду). Так как исключение нигде не обрабатывается, скрипт завершит работу и соединение с mysql будет разорвано. Так как autocommit не отключался, начатая транзакция с добавлением записи в историю будет автоматически закомичена (то есть запись в историю будет сохранена). А это уже противоречит предложению тикета... Поправь меня если я ошибаюсь.

[alx]

И еще позанудствую, раз уж все равно комментирую. :)

В коммите r153/base изменены сразу два файла. Причем очевидно, что изменение в файле css не имеют никакого отношения к данному тикету. Очевидно, они попали в коммит случайно. И подобные попадания "посторонних" изменений я видел уже много раз. Поэтому у меня просьба - прежде чем делать коммит, внимательно просмотреть все изменения (svn diff или git diff) и не объединять в один коммит изменения, логически не связанные друг с другом. Во-первых, такие коммиты трудно анализировать (приходится задумываться, каким образом изменение стилей CSS помогает установить правильный статус контроля ОТК), во-вторых, если потом по каким-то причинам захочется откатить изменение, простой реверт коммита откатит и изменение стиля тоже (чего не требовалось), в результате потребуется ручная работа по отделению одних изменений от других...