Косяк с "Доп данные клиента" - revision

[Elisium]

Замечен такой косяк:

Последовательность действий:

1. Завожу новое доп поле - "Операции - Настройки - Доп поля - Создать новое"
Называю поле "МАК адрес", шаблон "Техданные", тип "строковое однострочное"
Применяю на это дело регексп - (?:[0-9,aA-fF][0-9,aA-fF]\{5}[0-9,aA-fF][0-9,aA-fF]

2. Беру первую попавшуюся тестовую жертву (юзера вобщем)
Захожу в "Дополнительные данные", там вижу свое новое поле "МАК адрес"
Ввожу туда МАК ПРАВИЛЬНОГО ФОРМАТА ... Смотрю в БД - bill - dopdata
Все ок, все поля на месте, все ревизии ТОЖЕ ОДИНАКОВЫЕ ...

3. А вот теперь захожу опять в тогоже клиента в "Дополнительные данные"...
Вижу прописаный ранее мак - все норм .. Теперь ввожу мак НЕВЕРНОГО ФОРМАТА (ну ошибся оператор и не заметил - с кем не бывает), нажимаю "Сохранить".
Пишет чето типа "Ваши данные не совпадают с назначеным шаблоном" - чудненько, а ниже "Все изменения сделаны успешно" и кнопка "Назад"..
Нажимаем "Назад" и видим, что ВЕРНЫЙ мак, который там был ранее, ИСЧЕЗ .. там теперь ПУСТО!!!
Опять лезу в БД ... смотрю - первые три поля по умолчанию (скорости вверх/вниз и 25й порт) СОХРАНИЛИСЬ и имеют БОЛЕЕ НОВУЮ ревизию, а поле "МАК-адрес", само собой НЕ СОХРАНИЛОСЬ и имеет СТАРУЮ ревизию ... Изменяю для "чистО попробовать" поле "ревизия" в "Мак Адресе " на обновленную (такую, как у других полей), захожу в пользователя и хоба! мак опять на месте ...

Вывод: както некошерно работает отображение ревизий  - выбираются поля ТОЛЬКО с одним последним номером ревизии. НЕизмененное поле, но с ревизией меньше, чем остальные поля не выбирается из бд ... Правильнее было бы выбирать СТАРШУЮ ревизию в КАЖДОМ "Дополнительном поле", а не привязывать все поля к одной цифре .. Или записывать НЕизмененное поле с правильной версией ...
В итоге сейчас получается, что если оператор два раза ошибся с вводом мака и два раза нажал "Сохранить", то ревизия остальных полей увеличится два раза, а ревизия МАК поля не изменится, хотя само поле содержит верные данные ...

п.с. ах да - версия Нодени - 50.19

[Efendy]

С недоделанностью ввода ошибочных данных я согласен - действительно будет записано пустое значение. У меня есть идеи как исправить этот косяк.

А вводить на каждое поле свою ревизию  имхо неправильно. Шаблон данных - это неразрывное понятие.  Админ видит цельный блок данных. Он его изменяет. Даже если какие-то поля он не менял, но видит что поля соответствуют тому, что он хочет видеть - будут сохранены все данные как он желает. Если бы сохранялись только те данные, которые он менял - могли бы быть конфликтные ситуации. Например, есть 3 поля (А,Б,В), которые взаимосвязаны между собой. Админ видит А=1, Б=2, В=3. Он меняет А=4, Б=5, и не меняет В т.к. оно соответствует тому, что ему надо. При этом пока он редактировал данные, параллельно другой админ поменял А=6, Б=7, В=8, и успел сохранить. Первый админ сохраняет данные и получается невалидная комбинация А=4, Б=5, В=8.

Есть и другие причины не разделять каждое поле на ревизию. Например производительность. Скажем надо получить параметры скорости для абонента. Нам придется искать актуальную ревизию для входящей скорости, для исходящей, а может еще несколько параметров (порты блокировки, мак адрес, пароль, логин и т.д.) вычисление актуальной ревизии - это довольно неоптимальная операция в mysql - плохо он работает со всякими group by.

В общем, проблему я понял. Что-то решим.

[Efendy]

Походу, дополнительные поля требуют еще доработки. В 50.25 версии уже сделан нормальный поиск по дополнительным полям + сортировка, отображение истории изменения с табличками на каждую ревизию, т.е можно  проследить что менялось на каждом этапе. Что хотелось бы реализовать:
- поиск по неактуальным ревизиям
- в истории ревизий подсвечивать поля которые менялись с каждой новой ревизией
- написать доку как работать с допполями на уровне sql-запросов

[Elisium]

Вопрос номер два ..
В каком поле хранится САМ номер ревизии?
Просто очистивши таблицу Dopvalues, в Dopdata соответствующие поля становятся Null и когда уже на любом клиенте в Доп данных нажимаешь "Сохранить", то в УЖЕ ЧИСТОЙ табл Dopvalues появляются записи, но с большИм номером ревизии, как и до очистки ... ..
Вобщем, как сделать так, что бы ревизии опять с единицы начинались ?  

Для чего это - в скрипте для перевода поля МАКов с версии 48 в БД версии 50, ТОЖЕ есть поле Версии ..
Вот такой вот вопросец )))

[Efendy]

Ревизия берется из поля line_id, которое автоинкрементное. Если удалить данные путем delete from dopvalues, то последнее значение инкрементного поля сохраняется. Чтобы действительно очистить таблицу, надо юзать команду truncate - вроде так пишется

[Elisium]

Спасибо, попробую ..

п.с. кстати, почему в поставке биллинга в Апдейтах не идет скрипт перевода полей МАК с (допустим) 48й версии в 50ю ? И про это нигде не написано, что он все таки НУЖЕН ...
п.п.с. пришлось перерыть весь форум и подправить этот скриптик под себя ..

[Efendy]

Потому что нет фиксации поля "мак". Оно может быть занято под иное. Тем более сами разобрались