Основня задача каталога со стороны покупателя - это быстрый фасетный и полнотекстовый поиск. Как каталог хранит эти данные, покупателю наплевать. С этой точки зрения в статье нет никакой полезной информации. Сейчас этот код и метрики из предыдущей статьи не говорят ничего.
Если Вы построите запрос на поиск по 5 атрибутам и произвольному тексту одновременно и сраните результаты с аналогиными запросами в Эластике и Сфинксе, то тогда статья будет полезной.
Но что-то мне подсказывет, что после этого, Вы больше не будете разрабытывать библиотеку.
Так случилось, у меня есть опыт работы с этим решением более года, фиксил ошибки в ядре.
Не хочу показаться токсичным, но предупреждаю. Будте очень осторожны с выбором данного решения.
Мы застряли на версии 1.9.*, потому что самостоятельно фиксили ядро. И там много серьезных ошибок, повсеместные синглтоны при SSR из-за этого хуки модулей не работают, и т.п.
Возможно последняя версия лучше, лично я бы не стал наступать на теже грабли.
> можем ли мы в агрегации получить информацию о том, что если мы дополнительно выберем 49дюймов, то кол-во телевизоров увеличится до 70
можем, будет именно так. 52, 49 -это термины, агрегация позволяет получить количество по каждому термину. В фильтре можно выводить значение и количество: 52 (50 шт), 49 (20 шт). Если 0, то фильтр блокирует значение или скрывает.
Возможно, я не понял. Но именно эта проблема послужила основой для написания статьи. Для каждого фильтра нужно построить свое множество и на нем сделать агрегацию. Конструкция filter aggregation вместе с terms aggregation решают именно эту проблему.
Мы знали, что сможем написать веб-сервер на чистом PHP (PHP-PM) или с использованием С-расширения (Swoole). И хотя у каждого способа есть свои достоинства, оба варианта нас не устраивали — хотелось чего-то большего.
Слабоватые аргументы. Чем не устраивали? Вы же наверно что-то смотрели, с чем-то сравнивали. Можно об этом подробнее?
Например, есть такое решение github.com/amphp/http-server, есть тот же PPM.
Что-то можете сказать об этом?
Любой (вру, не любой, — адекватный) бизнес поднимет зарплату хорошему сотруднику, и не раз. Но только в ответ на экономический эффект от работы сотрудника. Проще говоря, ты приносишь фирме больше — она тебя весомее благодарит.
Как думаете, вы адекватный бизнес или нет? Какой процент таких адекватных бизнесов в РФ?
Как вы оцениваете экономический эффект программиста? В чем он по вашему заключается?
Как у вас измеряется, сколько программист принес бизнесу?
Как у вас рядовой программист может оказать экономический эффект? Для это организован какой-то бизнес процесс? Например, он может влиять на стратегические решения монетизации и т.п.?
Если программист качественно сделал работу, но отдел маркетинга слабый, это как-то влияет на доходы программиста?
"За бугром" также, Россия в этом вопросе не уникальна.
Основня задача каталога со стороны покупателя - это быстрый фасетный и полнотекстовый поиск. Как каталог хранит эти данные, покупателю наплевать. С этой точки зрения в статье нет никакой полезной информации.
Сейчас этот код и метрики из предыдущей статьи не говорят ничего.
Если Вы построите запрос на поиск по 5 атрибутам и произвольному тексту одновременно и сраните результаты с аналогиными запросами в Эластике и Сфинксе, то тогда статья будет полезной.
Но что-то мне подсказывет, что после этого, Вы больше не будете разрабытывать библиотеку.
Вторая версия это надстройка над Nuxt: модули, роутинг все оттуда. Первая версия превратилась в тыкву. Ну что сказать - ребята "молодцы".
Не хочу показаться токсичным, но предупреждаю. Будте очень осторожны с выбором данного решения.
Мы застряли на версии 1.9.*, потому что самостоятельно фиксили ядро. И там много серьезных ошибок, повсеместные синглтоны при SSR из-за этого хуки модулей не работают, и т.п.
Возможно последняя версия лучше, лично я бы не стал наступать на теже грабли.
Посмотрите это github.com/sascha245/vuex-simple, работает даже с SSR без всяких «танцев с бубном».
можем, будет именно так. 52, 49 -это термины, агрегация позволяет получить количество по каждому термину. В фильтре можно выводить значение и количество: 52 (50 шт), 49 (20 шт). Если 0, то фильтр блокирует значение или скрывает.
Слабоватые аргументы. Чем не устраивали? Вы же наверно что-то смотрели, с чем-то сравнивали. Можно об этом подробнее?
Например, есть такое решение github.com/amphp/http-server, есть тот же PPM.
Что-то можете сказать об этом?
А сообществу, думаю, было бы интересно посмотреть на метрики, критерий, и процессы. Может быть научиться чему-то.
Без фактов, статья похожа на нытье.
Потому что с работодателями (управлением кадрами, их уровнем менеджмента БП и т.п.) возможно большая проблема чем с кадрами.
Можно продолжить, но пока остановлюсь на этом.
По вашему примеру — не совсем вуаля, $tableName — должен существовать. А заставить его существовать никак нельзя.
Можно заставить существовать только метод, как метод, определенный в интерфейсе.
Если использовать ту же Доктрину и его QueryBuilder, то такие конструкции не нужны.