![[MC-04 logo]](/mc-04/chrome/site/logo.png){kind=logo}
Opened 41 hours ago
Last modified 17 hours ago
#1549 assigned дефект
исправить уже имеющиеся неконсистентности в БД
| Reported by: | Denis_N | Owned by: | san |
|---|---|---|---|
| Priority: | minor | Component: | БД изделий АДС |
| Keywords: | Cc: |
Description (last modified by )
По тикету (See #1394) нужно нормализовать данные несоответствий в бд. Подготовил скрипт для нормализации бд normalize_mismatch.php. Нужно опубликовать на сервере и открыть.
Назначаю задачу на san, так как у меня нет прав на изменение записей в бд.
Скрипт пересчитывает products.mismatch по следующим правилам:
- Если запись дефекта имеет status=fail или старое значение NULL, её bond указывает на номер N записи устранения со статусом ok, а bond устранения указывает обратно на этот дефект, то дефект считается закрытым. Обе записи должны относиться к одному изделию — иметь одинаковый UID.
- Если у изделия есть запись устранения со статусом ok, у которой bond=NULL или 0, и ни одна другая запись не ссылается на неё через bond, то скрипт считает её устранением по старой схеме. Если таких устранений несколько, используется последнее по дате; при одинаковой дате — с наибольшим N.
- Если запись дефекта имеет bond=NULL или 0 и находится до устранения из пункта 2, то дефект считается закрытым. Если находится после него, то считается открытым.
- Если у изделия нет записи устранения, соответствующей пункту 2, то дефекты с bond=NULL или 0 считаются открытыми.
- Если по этим правилам найден хотя бы один открытый дефект, то в products.mismatch записывается yes. Если открытых дефектов нет — no. Уже совпадающее значение не изменяется.
- Если bond указывает на отсутствующую запись, на другое изделие, на саму запись, на неподходящую запись либо отсутствует обратная ссылка, то изделие не исправляется автоматически. Оно попадает в «Для ручного разбора». Туда же попадают случаи с неизвестными статусами и отсутствующими датами, необходимыми для определения порядка событий.
Под дефектом понимается запись, у которой type_write содержит mismatch, а status=fail или NULL. Под устранением — запись со статусом ok, у которой type_write содержит mismatch
«Проверить» ничего не меняет. «Исправить» изменяет только products.mismatch. История и значения bond не переписываются.
Change History (17)
comment:1 by , 41 hours ago
| Description: | modified (diff) |
|---|
comment:2 by , 41 hours ago
| Description: | modified (diff) |
|---|
follow-up: 5 comment:4 by , 24 hours ago
Replying to alx:
То есть предлагается дать возможность любому желающему жителю Земли исправлять дефекты в таблице
products. Я правильно понял? Если да, то хорошо ли и правильно ли так делать? Последний вопрос - риторический...
Думаю, что ты неправильно понял.
Денис предлагает мне загрузить файл на сервер, выполнить его один раз, а затем удалить. Т.е. не любому, а только мне(аутентификацию я пройду подключаясь к серверу).
comment:5 by , 24 hours ago
Replying to san:
Думаю, что ты неправильно понял.
А, хорошо. :)
не любому, а только мне(аутентификацию я пройду подключаясь к серверу).
В таком случае, я не могу найти в приложенном файле место, где проверяется, что 1) обратившийся клиент аутентифицирован и 2) что это ты. Не мог бы ты или автор тикета подсказать, в каких строках файла находятся эти проверки?
follow-up: 9 comment:6 by , 24 hours ago
В файле нет проверок. Предполагается, что загрузить файл на сервер может только аутентифицированный пользователь.
follow-up: 10 comment:7 by , 24 hours ago
То есть предполагается, что san опубликует файл не известный никому коротки отрезок времени. "Нажмет" исправить, после нажатия "Исправить", он еще какое-то посмотрит раздел для ручной проверки и удалит файл
comment:8 by , 22 hours ago
По файлу отбой. Буду постепенно передавать san sql-код, для точечных исправлений
follow-up: 11 comment:9 by , 21 hours ago
Replying to san:
В файле нет проверок. Предполагается, что загрузить файл на сервер может только аутентифицированный пользователь.
В таком случае, это ты неправильно понял мой вопрос в comment:3. Я там говорил не о загрузке файла на сервер, а о выполнении загруженного файла (путем посылки соответствующего HTTPS запроса).
Вопрос из comment:3 по-прежнему актуален.
comment:10 by , 21 hours ago
Replying to Denis_N:
То есть предполагается, что san опубликует файл не известный никому короткий отрезок времени. "Нажмет" исправить, после нажатия "Исправить", он еще какое-то посмотрит раздел для ручной проверки и удалит файл
Спасибо за пояснение.
Во-первых, я не вижу в описании тикета указания удалить файл после завершения работы с ним. Владелец тикета, например, вполне может решить оставить файл на случай, если когда-нибудь снова потребуется "отремонтировать" подобные неконсистентности.
Во-вторых, ограничение времени существования файла на сервере, действительно, уменьшает вероятность возможной атаки, но не исключает ее. Искренне не понимаю, зачем полагаться на вероятность (сколь бы низкой она ни была), если можно, добавив несложную проверку, полностью это исключить...
Предлагаю еще раз подумать, стоит ли загружать на сервер скрипты, которые могут модифицировать БД, без аутентификации пользователя. Это предложение касается не только данной конкретной проблемы (см. #1394), но и, например, работы неаутентифицированных пользователей со складом...
comment:11 by , 21 hours ago
Replying to alx:
Вопрос из comment:3 по-прежнему актуален.
Replying to Denis_N:
По файлу отбой. Буду постепенно передавать san sql-код, для точечных исправлений
Мы пообщались с Денисом и пришли к договорённости, что неконсистентности будем устранять по шагам, и, если возможно обычными командами sql(простыми и понятными), для большего контроля процесса. Процесс ответственный, можно потерять данные, если ошибёшься.
follow-up: 13 comment:12 by , 21 hours ago
Есть другая идея. Отказать от products.mismatch. Флаг несоответствий в "Списке изделий" может вычисляться из таблицы history. Но тогда теряется после исправления несоответствия, дополнительная проверка со стороны Светланы, что несооответствие устранено. Но нужна ли эта проверка? Как считаете?
comment:13 by , 20 hours ago
Replying to Denis_N:
Есть другая идея. Отказать от products.mismatch. Флаг несоответствий в "Списке изделий" может вычисляться из таблицы history. Но тогда теряется после исправления несоответствия, дополнительная проверка со стороны Светланы, что несооответствие устранено. Но нужна ли эта проверка? Как считаете?
Я не понимаю, ни зачем нужна дополнительная проверка того, что несоответствие устранено, со стороны Светланы, ни почему при устранении поля products.mismatch эта проверка теряется.
Если говорить о технической стороне вопроса, то, насколько я понимаю, поле products.mismatch было добавлено исключительно для ускорения работы - для более быстрого вывода списка изделий с указанием, имеются ли в них несоответствия (попросту говоря, признаком "годное"/"негодное"). Так как это избыточная информация (как ты сам сказал, она может быть получена из таблицы history), при ее удалении ничего не должно потеряться (кроме скорости работы).
follow-up: 16 comment:14 by , 18 hours ago
Да, про Светлану - это я затупил, я имел ввиду отразится ли на ОТК в продуктах, но нет, не отразится
comment:16 by , 17 hours ago
Replying to Denis_N:
я имел ввиду отразится ли на ОТК в продуктах, но нет, не отразится
Если я ничего не путаю, то аггрегированное состояние контроля ОТК находится в поле products.otk, а не в products.mismatch...
comment:17 by , 17 hours ago
Replying to Denis_N:
В r677/base код теперь не зависит от Products.mismatch
В сообщении коммита сказано, что поле products.mismatch более не обновляется, но при этом сохранено в БД. Поясни, пожалуйста, для чего это поле сохранено в БД, если оно более не обновляется, то есть не содержит информации о продукте?
В первой же строке приложенного файла я вижу такой комментарий:
То есть предлагается дать возможность любому желающему жителю Земли исправлять дефекты в таблице
products. Я правильно понял? Если да, то хорошо ли и правильно ли так делать? Последний вопрос - риторический...