2 часа назад
Давай попробуем вот так — youtu.be/BbyfFDARgZU
mmxApp - разработка новых composer дополнений 4
7 часов назад
Не знаю, не помню когда в последний раз использовал эту конструкцию. Раньше да, помнится были какие-то проблемы.
Мне кажется, лучше пройтись по шаб...
Парсер fenom в шаблоне без конфликтов... 5
9 часов назад
Сам относительно недавно столкнулся с проблемами phpThumb. Насколько помню в последних релизах modx была версия phpThumb, которая работала только с ph...
Вышел MODX 2.8.7 - починили превью, можно обновляться! 10
9 часов назад
Мне вообще не нравится, что файлы дополнений раскиданы по всей системе… часть в assets/name, другая в core/name, а третья получается еще и в _build/na...
Эксперимент с Modx Extra + Docker 13
22 апреля 2024, 17:19
Я нафигачил просто несколько условий
Разные цены для разных групп покупателей 7
22 апреля 2024, 12:57
Данная ошибка в логе никак не связана с проверкой доступа по модификатору pasraccess.
Можете написать в ТГ в профиле.
[PayAndSee] - Версия 2.0 55
20 апреля 2024, 16:08
Смотрите ошибки в консоли браузера.
[СДЕЛАЙ САМ] SendIt и MiniShop2 - заказ в 1 клик - быстро, просто и бесплатно. 59
20 апреля 2024, 15:47
{set $data = id_ресурса | resource : 'название_тв_migx' | fromJSON}
{foreach $data as $item}
{$item.name}
...
Получение tv поля ресурса 5
19 апреля 2024, 12:48
Постараюсь в свободное время это сделать, спасибо за предложение
[FetchIt] - Полноценная замена AjaxForm без зависимостей 59
тык
Исходя из этого бенчмарка Lucinda быстрее laravel в 47 раз
За что я ненавижу Eloquent ORM а также тысчи подобных статей и обсуждений к ним
Конечно еще сильнее становится заметно чем обычный hello world, чем больше связей, чем больше данных тем более заметно, но это все не критично, laravel — идеальный php фреймворк, его выбирают за простоту работы, за то, насколько просто найти разработчика на него и насколько быстро можно реализовывать фичи, если недостаточно laravel'я, то стоит задуматься не о других фреймворках, а о других ЯП уже
Оооо… тут вообще можно бесконечно рассуждать, говоря о кешировании, вы как, батенька кешируете? Например если ты кешируешь в файловую систему, то, забрать из fs будет сильно дороже по ресурсам и времени, нежели забрать из БД с правильными индексами. По другому обстоят дела если это memcached или redis, но тут будут и другие подводные камни, мы же говорим о базовой реализации, не так ли?
Та же eloquent содержит в себе сильно больше логики и обвязки (потому что хочет быть похожей на ORM, но ей не является) чем пусть и кривоватый, но конструктор запросов под названием pdoTools
Боюсь что он будет даже отрицательный, нежели положительный
Не меняя подход к выборке (например параллельные запросы), не меняя архитектуру базы данных, не проставляя индексы какое время вы хотите выиграть? А прослойка в виде api скорее всего только тормозит результаты
1) Зачем тут использовать laravel? Какие он преимущества даст, кроме собственного удовлетворения что теперь то «все красиво»
2) В быстрой фильтрации важнее правильные индексы и в принципе архитектура бд, laravel на это никак не повлияет
3) «Микросервисы» на PHP сложно назвать микросевисами, хотя бы потому, что они обмениваются по json api (вместо gRPC например) который медленный и сильно нагружает сеть, я уже молчу о том, что сам laravel сильно тяжелее того же modx
По мне лучше бы показал как интегрировать какой нибудь легковесный полнотекстовой поиск, по типу meilisearch и на основе него уже построить фильтрацию, а уже что там будешь использовать для обращения к api meilisearch laravel, modx или нативный php уже не важно
Так хотя бы профит будет
Очень много работал с пуппетером и его аналогами в ноде, go в этом плане сильно удобнее т.к. может группировать процессы на отдельные потоки, может например запустить браузер и держать его запущенным а каждую вкладку обрабатывать отдельным потоком, убивается поток — убивается вкладка и никаких memory leak
А для каких дел он тогда предназначен, если не может построить оптимальный запрос?
Не знаю, я все таки считаю что сравнивать с newQuery не корректно, newQuery просто транслирует php команды в SQL код, он не автоматизирует ничего и не упрощает
И код на newQuery будет скорее всего похож по количеству и структуре на выходной SQL
Потому что в случае с getCollection не надо джойнить tv, а можно их получить через getTVValue через модель собственно
Главная причина почему пришлось писать билдер, это адская структура таблиц тв полей и сложность джоина каждого из параметров