на вкус и цвет, но по ошибкам рест рулит

Ну вот пользователь меняет свою дату рождения. Отправляет дату аяксом. В ответ пришло 200. Достаточно?

тут найдется хх как минимум с советами status: ok или status: error

Так вот я это и имею в виду. Это обязательно, желательно или в этом нет необходимости?

это на вкус и цвет, я не считаю это хорошей практикой. Это пережитки 200х

То есть лучше конкретизировать все таки?

Пока что понял, что единого мнения нет: делай, как считаешь нужным

просто нет желания навязывать свое) в быстрых проектах нет смысла заморачиваться, а крупных вообще можно работать через единый рест. Если на фронте самописные ajax на каждый пчих то все равно что ты будешь использовать, если какой-нить ангуляр то смысла нет спрашивать и так понятно что надо вернуть ) Это специфично, нет смысла думать что надо делать только так.

а как вы храните настройки пользователей? например, где указываете currency для пользователя.

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

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

Таблица наподобие userId, settingKey, value?

Но и json имеет недостатки. Например, поиск по этому полю, или добавление новой настройки всем юзерам в их json

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

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

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

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

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

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

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

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

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

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

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

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

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

точно

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