последний мускул также поддерживает.

Не юзал никогда поля json не в курсе возможностей. Но как по мне в таком формате настройки лучше не хранить

вместо одной таблицы с json параметром Вы предлагаете использовать 2, да еще и заморачиваться с сохарнением в каждую из них. и почему настройки лучше не хранить в формате json?

есть объективные показатели или просто нет опыта использования?

вместо одной таблицы с json параметром Вы предлагаете использовать 2, да еще и заморачиваться с сохарнением в каждую из них. и почему настройки лучше не хранить в формате json?

На мой взгляд, лучше всего сделать отдельное поле. Промежуточная таблица нужна скорее когда надо часто и много данных менять или добавлять.

есть объективные показатели или просто нет опыта использования?

Нет опыта использования. Не попадалась задача, когда хранение данных в базе в json дало бы какие то преимущества

ребят привет. надо при сохранении модели получить поля которые были изменены. как сделать?

ребят привет. надо при сохранении модели получить поля которые были изменены. как сделать?

https://www.yiiframework.com/doc/guide/2.0/en/db-active-record#dirty-attributes вот это?

да. какраз нашел только что)) спасибо)

ребята, подскажите идею как реализовать следующее: в црм есть события, которые повторяются через определенные промежутки времени, например событие повторяется каждый вторник, в БД хранится день недели в который оно срабатывает и timestamp ближайшего срабатывания, крон пробегается по здачам, которые должны сегодня сработать и переносит timestamp на следующий вторник. Заказчик хочет чтобы повторяющееся событие в таблице списка событий было выведено несколько раз, т.е. например если выбран интервал 1 мес., то нужно чтобы это событие было выведено в каждом вторнике, а если ежедневное событие, то в каждом дне его выводить. Записывать в БД на будущее сразу на все вторники? Но тогда сколько этих записей должно быть на будущее? )) Или можно как-то клонировать эту запись уже после выборки из БД?

ребята, подскажите идею как реализовать следующее: в црм есть события, которые повторяются через определенные промежутки времени, например событие повторяется каждый вторник, в БД хранится день недели в который оно срабатывает и timestamp ближайшего срабатывания, крон пробегается по здачам, которые должны сегодня сработать и переносит timestamp на следующий вторник. Заказчик хочет чтобы повторяющееся событие в таблице списка событий было выведено несколько раз, т.е. например если выбран интервал 1 мес., то нужно чтобы это событие было выведено в каждом вторнике, а если ежедневное событие, то в каждом дне его выводить. Записывать в БД на будущее сразу на все вторники? Но тогда сколько этих записей должно быть на будущее? )) Или можно как-то клонировать эту запись уже после выборки из БД?

Календарь чтоль нужен?

Календарь чтоль нужен?

да

загвоздка именно с повторяющимися событиями, с запланированными все просто, они выводятся в дату, на которую запланированы.

загвоздка именно с повторяющимися событиями, с запланированными все просто, они выводятся в дату, на которую запланированы.

У вас есть день недели(день месяца), я сделал бы так, брал текущий день недели(заданный) и искал совпадения, если есть то что-то выводил... Как-то так, решение в лоб

т.е. в цикле перебирать не массив событий, а дни заданного диапазона (например за месяц) и сверять день недели? Тогда не получится сортировать и фильтровать таблицу по атрибутам события.

вот макет с повторяющимися событиями https://monosnap.com/file/7S34IW9972M2wkYFeSCWW70XSCs8Q3.png

т.е. в цикле перебирать не массив событий, а дни заданного диапазона (например за месяц) и сверять день недели? Тогда не получится сортировать и фильтровать таблицу по атрибутам события.

Сделать сложный sql запрос а не средствами php, до компа доберусь попробую составить

ребята, подскажите идею как реализовать следующее: в црм есть события, которые повторяются через определенные промежутки времени, например событие повторяется каждый вторник, в БД хранится день недели в который оно срабатывает и timestamp ближайшего срабатывания, крон пробегается по здачам, которые должны сегодня сработать и переносит timestamp на следующий вторник. Заказчик хочет чтобы повторяющееся событие в таблице списка событий было выведено несколько раз, т.е. например если выбран интервал 1 мес., то нужно чтобы это событие было выведено в каждом вторнике, а если ежедневное событие, то в каждом дне его выводить. Записывать в БД на будущее сразу на все вторники? Но тогда сколько этих записей должно быть на будущее? )) Или можно как-то клонировать эту запись уже после выборки из БД?

Храни только номер дня недели. Вычисляешь ближайшую дату на этот день, остальные через интервал. Все средствами бд

Можешь конечно лог срабатываний вести

вот макет с повторяющимися событиями https://monosnap.com/file/7S34IW9972M2wkYFeSCWW70XSCs8Q3.png

я на днях реализовал идентичную задачу

вот макет с повторяющимися событиями https://monosnap.com/file/7S34IW9972M2wkYFeSCWW70XSCs8Q3.png

только у меня задачи еще и на паузу можно ставить :)

так вот, основная мысль: для каждой задачи, независимо от того, будет она сейчас выполняться или нет, считать next_run и записывать в поле базы

а дальше кроном ловить задачи, у которых next_run <= now, не забывая потом высчитать новый next_run

а дальше кроном ловить задачи, у которых next_run <= now, не забывая потом высчитать новый next_run

Я так и делаю, но загвоздка в том как вывести повторы в будущем

задач много?

сколько ноликов?

Пока мало до тысячи, систему только начали делать

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

смысл - не клонировать их в базе, там должна быть одна запись просто при выборке добавляешь виртуальные повторы

так как клон от оригинала отличается только датой следующего запуска, можно даже __clone у модели переделать работа с datetime - быстрая штука по факту, ты можешь в оперативке хоть все задачи клонировать главное, чтоб оперативки хватало, ибо ООП - тяжелая хрень в плане памяти

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

вот тут со второго пункта не очень понял ☺️ из БД я же уже получаю отсортированный массив, как в него добавить клоны и снова отсортировать?

uksort() ?

нужно перебрать модели в датапровайдере и добавить туда клоны с сортировкой, верно?

точно

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

а чо нельзя как крон запись хранить эти задачи? вроде парсер под крон выражение в пыхе есть

позволяет как периодические записи хранить, так и одиночные

имею в виду` */30 * * * *` эту херь

mod_fcgid: HTTP request length 138140 (so far) exceeds MaxRequestLen (131072) как это исправить?

когда был ISP небыло проблем теперь VEstaCP появилась проблема )))

когда был ISP небыло проблем теперь VEstaCP появилась проблема )))

удали ваще все панели, зачем это дерьмо нужно?

?

у меня и так стресс уже, сейчас попробую типа такого запихнуть в цги файл export PHP_FCGI_MAX_REQUEST_LEN=604857600

Элфиндер оказалось рубит по 10 метров файл и заливает на хост))? прикольно, я то думал ограничения пхп на выгрузку работают а неет))

имею в виду` */30 * * * *` эту херь

там вопрос был как это все вывалить в календарь тут крон ридер не сильно поможет

там вопрос был как это все вывалить в календарь тут крон ридер не сильно поможет

почему? звезды заменяй на текущую дату и все

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

вот в том и дело, что все равно нужно считать каждое "срабатывание"

а уже как считать - зависит от формата хранения можно крон синтаксис, можно какие-то циферные интервалы

ну у нас есть конечная дата (когда 1 срабатываение), и периодическое срабатываение. как это объеденить в 1 формат?

есть предложения? )

имхо формат крона решает проблему

повторюсь: решал схожую задачу, но чуть с другими условием

у меня "повторять каждые n x с момента постановки", где n - int, x - минуты, часы, дни, блабла

у меня "повторять каждые n x с момента постановки", где n - int, x - минуты, часы, дни, блабла

ну это 2 записи в бд будет

одна

зачем две?

1 старт, вторая период

а как ты период сделаешь в таком случае?

created_at, а дальше Carbon и добавляешь нужный интервал, сохраняя туда же в базу

как-то сложна

created_at может текущий быть, а период начинаться завтра в 2 часа и каждые 2 часа

можно start_at сделать для задачи, и дальше к этой дате интервал добавлять

все же от постановки задачи танцует

у меня - с момента создания

На кроне. По утрам. Ежедневно проверяем, нет ли назначенных цикличных событий на текущую дату. Если есть - добавляем в БД копию цикличной.

Как-то так. И выборка не будет всю базу ворошить. Для цикличных отдельная таблица.

нахрена базу засорять? это раз два: в той задаче надо было показать и будущие задачи, которые еще не настали

​​PHP. Рецепты программирования (2015) Авторы: Дэвид Скляр, Адам Трахтенберг #php #books О книге Дэвида Скляра, пожалуй, должен знать (а ещё лучше — прочитать) каждый начинающий или опытный веб-разработчик. В этом объёмном руководстве вы найдёте множество профессиональных прикладных решений для самых распространённых задач в веб-разработке. В книге разбираются не только основы языка PHP и его объектно-ориентированные возможности, но даны также готовые рецепты по работе с аутентификацией пользователей, с сессиями, графическими изображениями, функциями PHP, исключениями и тестами. В книге рассматриваются следующие темы: ➕ основы веб-программирования; ➕ формы; ➕ базы данных; ➕ сеансы и долгосрочное хранение данных; ➕ обработка ошибок; ➕ регулярные выражения; ➕ написание тестов и многое другое. Недостатки: ➖ версия языка PHP — 5.4.

Хм, а как грамотно сделать: нужно в Assets некоторые скрипты вынести в head, но некоторые так и должны быть в перед закрывающим тэгом body, т.е. public $jsOptions = ['position' => \yii\web\View::POS_HEAD];, по-идеи, не поможет?

Нет. Проще разделить на 2 asset ... Ну или делать проверку в public init() и там позицию задавать

Нет. Проще разделить на 2 asset ... Ну или делать проверку в public init() и там позицию задавать

Спасибо за совет!

можно вообще ассетсами не пользоваться. ибо нах они? цепляем 1 собраный и минифицированный файл и ебись оно конем =)

можно вообще не генерировать фронт со стороны сервера :)

и пошло оно все к чертовой матере

Радикалы

прости, ради чего?

можно вообще не генерировать фронт со стороны сервера :)

в одну каску это сложна делать :(

а так да, нах эта генерация хтмл сраная

фронтяка сейчас не такая и сложная, можно и в одну будку

@shindakioku расскажи нам про микросервисы, ангуляр и дарт

я с командами работаю, продуктивность выше

фронтяка сейчас не такая и сложная, можно и в одну будку

переключаться тяжело. фронт кодить как-то подругому получается чтоли.

Tefrin или Tervin что лучше по звучанию

для чего?

Какая разница для чего)) главное чтоб благозвучно было

Тервин лучше

Тервер

Вызовет дрожь у причастных лиц

Tevin

Тервер

перекрестился

Ы

Тэрвин 60%

Набирает голосов

Тэрвин 60%

Два раза в сутки перорально?

Натощак

Два раза в сутки перорально?

Сублингвально? если ты понимаешь, о чем я)

Дык