ИЛ
Алексей Кузнецов
если искать по числовым полям или полным совпадениям, то солар особо профита не даёт
ты замерял?
Size: a a a
2020 August 21
ИЛ
А для вьюшек никакого нормального решения не появилось по фильтрации exposed-фильтров в зависимости от выбранных значений в соседних фильтрах?
оно ж от индекса зависит
NM
Как вы думаете? Если я выполнил команду
drush config-set update.settings check.interval_days 9348553245 -y и на странцие проверки обновлений модулей получаю ошибку для случаев когда друпал нашёл новые обновленияSQL error: Numeric value out of range for column 'expire' at row 1: Update {key_value_expire}
Это баг или нет? Стоит про это написать на друпал орг чтобы лучше проверяли входные данные перед записью в базу?Так там int, и скорее всего тот что лимитирован 2147483647.
AK
оно ж от индекса зависит
это если на базе search api делать, а если просто на базе сущностей и entity_reference (аля как таксономия)
АК
ты замерял?
да, по частичным совпадениям текста солар в 17 раз быстрее. По числовым полям то на то вышло
ИЛ
это если на базе search api делать, а если просто на базе сущностей и entity_reference (аля как таксономия)
это если на чём угодно делать
оно зависит от индекса, а не друг от друга
оно зависит от индекса, а не друг от друга
AK
Алексей Кузнецов
да, по частичным совпадениям текста солар в 17 раз быстрее. По числовым полям то на то вышло
когда база из тыщи значений - то да, а у меня там от силы будет 100 городов и 30 типов, ради этого таких тяжеловесов как solr завозить ваще смысла нет, если уж распухнет база - то да, завезём. У меня на другом проекте вон Solr фильтрует базу из 4 мильёнов записей за доли секунды.
AP
Так там int, и скорее всего тот что лимитирован 2147483647.
вопрос больше риторический.
Мол смотрите, я нашёл способ стрелять себе в ногу! вот инструкция из 16 пунктов как это провернуть!!! ВАЩЕ РУЖЬЁ НЕБЕЗОПАСНО!!!!
- баг или "ну ок"?
Мол смотрите, я нашёл способ стрелять себе в ногу! вот инструкция из 16 пунктов как это провернуть!!! ВАЩЕ РУЖЬЁ НЕБЕЗОПАСНО!!!!
- баг или "ну ок"?
АК
когда база из тыщи значений - то да, а у меня там от силы будет 100 городов и 30 типов, ради этого таких тяжеловесов как solr завозить ваще смысла нет, если уж распухнет база - то да, завезём. У меня на другом проекте вон Solr фильтрует базу из 4 мильёнов записей за доли секунды.
я на 200 тысяч проверял. То что у тебя солр фильтрует быстро - это понятно. Но mysql по числовым полям отфильтровал бы так же быстро, просто ты не пробовал)
AK
это если на чём угодно делать
оно зависит от индекса, а не друг от друга
оно зависит от индекса, а не друг от друга
дык а как сделать, чтобы дропдаун "тип магазина" фильтранулся по значению фильтра "город"? Хуком перехватывать и добавлять в запрос вручную этот фильтр, или что-то встроенное есть?
ИЛ
дык а как сделать, чтобы дропдаун "тип магазина" фильтранулся по значению фильтра "город"? Хуком перехватывать и добавлять в запрос вручную этот фильтр, или что-то встроенное есть?
пишешь свой контроллер и не паришься
AK
Алексей Кузнецов
я на 200 тысяч проверял. То что у тебя солр фильтрует быстро - это понятно. Но mysql по числовым полям отфильтровал бы так же быстро, просто ты не пробовал)
Там у меня он вааще фильтрует по geolocation координатам, нужно среди мильёнов грузов - найти все грузы, которые были отправлены от gps-точки + радиус 100км, это mysql ниасилит. Ну а так-то да, по индексированным полям и mysql миллионы записей ворочать будет норм.
NM
вопрос больше риторический.
Мол смотрите, я нашёл способ стрелять себе в ногу! вот инструкция из 16 пунктов как это провернуть!!! ВАЩЕ РУЖЬЁ НЕБЕЗОПАСНО!!!!
- баг или "ну ок"?
Мол смотрите, я нашёл способ стрелять себе в ногу! вот инструкция из 16 пунктов как это провернуть!!! ВАЩЕ РУЖЬЁ НЕБЕЗОПАСНО!!!!
- баг или "ну ок"?
Так зависит от схемы int для конфига в БД. Скорее всего не баг, а норма.
NM
Возможно там есть bigint для таких случаев. Просто данному конкретному конфигу не надо это. Это же всё схема определяет locale.schema.yml
АК
Там у меня он вааще фильтрует по geolocation координатам, нужно среди мильёнов грузов - найти все грузы, которые были отправлены от gps-точки + радиус 100км, это mysql ниасилит. Ну а так-то да, по индексированным полям и mysql миллионы записей ворочать будет норм.
вот тут ты опять же погнал. У меня без проблем из 40 тысяч записей mysql выбирает геофилд по радиусу от точки
АК
всё, что касается выборок с числами, в том числе с вычислениями - mysql с этим отлично справляется
AK
Алексей Кузнецов
вот тут ты опять же погнал. У меня без проблем из 40 тысяч записей mysql выбирает геофилд по радиусу от точки
хм... надо будет проверить, а то чёт начитался что mysql такими задачами лучше не грузить и сразу solr подключил
АК
если есть поиск по тексту, то солр точно нужен. Ну и ещё, если нагрузка большая, то солр помогает просто разгрузить базу и ускорить всё хотя бы за счёт перераспределения ресурсов
AK
А для вьюшек никакого нормального решения не появилось по фильтрации exposed-фильтров в зависимости от выбранных значений в соседних фильтрах?
О, в модуле https://www.drupal.org/project/views_dependent_filters есть dev-версия для 8.х но чёт с 2017 года её не тыкали палочкой, видимо ниасилилась ;(