YII: Шаблон модели при использовании CRUD генератора

Не понятно почему, но CRUD не создает самостоятельно модель для работы с таблицой БД. По крайне мере у меня. Потому из нескольких разрозненных кусков собрал «рыбу»:

YII2: Bad Request (#400) Unable to verify your data submissionYII2:

Такая ошибка:

Bad Request (#400) Unable to verify your data submissionYII2

может возникнуть при принудительном вызове формы с POST или GET параметрами со страницы сайта. Например:

В контроллере сайта код вида :

Как раз и приведет к подобной ошибке:

Это своеобразная защита фреймворка от потенциального флуда. Вариантов решения несколько:

Отключить проверку CSRF глобально:

Отключить проверку для конкретного контроллера:

Или воспользоваться ПРАВИЛЬНЫМ по мнению фреймворка методом:

YII2: авторизация через Active Directory в шаблоне basic

Почти наверняка это делается легко и не принужденно, каким то другим способом, более стандартным, но: Мы не ищем легких путей (с). Поэтому велосипед.

Для начала в файле params.php добавим настройки необходимые для соединения с AD:

Далее изменим модель User.php следующим образом, добавив в него следующие функции:

И там-же заменим функцию:

В модели LoginFrom.php изменим функцию login():

В результате получим собственно возможность авторизации через AD, с сохранением пользователя AD если такового в БД нет, в базе данных.

PHP: интересное поведение сложения чисел типа float

Был немножно удивлен сегодня, когда пытался сложить два числа типа float обычным оператором +. Например сложение чисел вида 59.86601 + 0,01 успешно выполнялось, а 59.86601+0,001 уже нет. Т.е. результирующее число оставалось прежним. Оказывается для точного сложения чисел, в PHP нужно использовать специальные операторы:

Например:

Быстрый поиск разницы файлов

Ну собственно это история одной маленькой победы, которые происходят обычно у ИТишников каждый день 😉

Предыстория: при работе скрипта по заливке данных в БД из файла произошло зависание сервера. Скрипт работал в несколько потоков с одним файлом. Потому определить на каком именно месте файла произошла остановка не представлялось возможным. Удалять уже залитое в БД и стартовать скрипт заново — не вариант, скрипт и так работал двое суток, и терять их снова — ну так себе решение.

Решение №1. «В лоб». Ну думаю доработаю скрипт так, что если данные уже есть, то просто пропускаем. Т.е. перед вставкой выполняем проверку функцией вида:

И без проблем дозальем то, чего нет в БД. Да не тут то было, оказывается операция select в этом случае весьма дорогостоящая, и т.к. в БД записей порядка 600тыс, и индексы проставлены на ls и period корректно, но всёж скорость проверки крайне низкая, и т.о. скорость «дозалития» сокращается с двух суток до суток. Ну что собственно не устраивает.

Решение №2. Вдумчивое. Решил было выгрузить ключевые строки (лицевой счет) в файлы: файл ls_in_base.txt — лицевые счета которые уже в БД и ls_all.txt — файл со всеми лицевыми счетами, которые должны быть в БД, отсортировав их командой sort:

Далее воспользуемся Linux командой comm, вычленив уникальные записи файла ls_all которые не содержаться в файле ls_in_base:

И далее уже в скрипте вместо проверки наличия лс в БД при помощи запроса, проверяем наличие лс в БД при помощи in_array:

В результате скорость увеличилась в разы, и БД дозалить удалось в течении часа

1 2 3 4 5 22