Я сейчас из одной конторы ушел, там работа добавить слайдер, убрать слайдер, а сейчас ищут разработчика, который должен знать phpunit, опыт от 3 лет, знания шаблонов, линукс AWS, и т.д.
Читать полностью…Параметры тарифа: 1 CPU, 1 Гб RAM, от 15 Гб до 40 Гб SSD ларавел запустится на нем?
Читать полностью…В теории теория и практика неразделимы. На практике они чаще несовместимы)
Меня много раз спрашивают за архитектуру проекта и ни разу в таких вопросах не было солидов и прочего, т.к. это неуместно спрашивать ибо вопрос про архитектуру, а не реализацию.
хз, на мой взгляд выглядит норм и главное не супер сложно
тегирование будет выглядить примерно так: ты хранишь все связи для твоей сущности вместе с состоянием, при чём на каждое изменение состояния дочерней сущности ты соответственно должен менять состояние родительской - это оправдано, если кол-во проверок будет сильно больше, чем кол-во изменений (по аналогии с соотношением запись/чтение в вебе)
но повторюсь, твой вариант вполне норм, если бизнес это устраивает
> - В пользовательском интерфейсе нужно будет сразу показывать кнопку экспорта, даже если это еще не доступно
тут была надежда, что если это условно 5 сущностей и у миллиона пользователей они совпадают - то можно в фоне просто считать всегда и поддерживать стейт) но раз их много - не прокатит
Подскажите а чистый SQL есть смысл зубрить? Просто обычно я все запросы делаю используя ORM
Читать полностью…он запустится на 50mb ram , кроме ларавеля есть еще много чего что на сервере должно быть
Читать полностью…Оно в целом работает как нужно, если не наткнуться на сущность у которой на одном из этапов возникли какие либо ошибки (сейчас работает вовсе без проверок).
В целом, вложенная проверка тоже будет выполнять свою задачу, но у меня есть уверенность в том, что такое "архитектурное" решение не верно
Тут надо конечно смотреть в целом на ситуацию, но как-будто ничего красивого прям не придумать:
можно например поддерживать состояние и связи сущностей - что-то по аналогии с тегированным кэшом, но хз насколько это оправдано
Да, сущностей много, и вложенность может быть объемная и глубокая
Можно привести параллель с музыкальным исполнителем.
У исполнителя есть релизы,
у релизов есть треки,
у треков есть жанры, и снова таки исполнители
Помогите мыслями.
Есть сущности, каждая из них проходит несколько этапов:
- индексацию (добавление в базу)
- синхронизацию (выгрузку физических файлов которые связаны с этой сущностью)
- экспорт на основной сервер (с этим заминка).
При этом у каждой сущности есть ряд состояний по этим этапам
- Индексирована
- Синхронизирована
- Не синхронизирована
- Синхронизирована с ошибками
-...
Экспорт может быть как одной отдельной сущности (только ее запись), так и полной схемы этой сущности, т.е со всеми ее связями и связями связей ...
Если мы экспортируем одиночную сущность, то проблем нет, мы явно можем проверить ее статус, т.е разрешает ли он начало экспорта этой сущности или нет.
Но если сущность нужно экспортировать с ее полным багажом, здесь не очень ясно как проверять, можно ли запустить такой экспорт или нет, ведь где-то в глубине связей может быть сущность, которая не может быть на данный момент экспортирована (например по ней еще идет джоба).
Есть мысль реализовать интерфейс с методом который будет проверять полную вложенность на предмет разрешено или не разрешено, но с этим есть свои минусы:
- В пользовательском интерфейсе нужно будет сразу показывать кнопку экспорта, даже если это еще не доступно.
- Пользователь сразу не сможет получить ответ, что экспорт запрещен или запущен, поскольку такая проверка требует времени и будет происходить в очереди.
- Сама логика решения выглядит не очень
У кого есть идеи получше ?