#ruby-on-rails #activeadmin
#ruby-на-рельсах #activeadmin
Вопрос:
По мере масштабирования нашего приложения у нас появляется множество таблиц с миллионами записей, и некоторые соглашения ActiveAdmin начинают нас подводить.
Соглашение ActiveAdmin заключается в простом объявлении набора различных фильтров, которые работают в определенной области поиска, и ActiveAdmin автоматически применит все эти фильтры к области, в дополнение к применению области, установленной вашим адаптером авторизации (например, из возможности CanCan).
Но с миллионами записей в таблице такой подход позволяет любому администратору очень легко указать набор фильтров, которые в сочетании друг с другом вызывают патологически дорогостоящий запрос Postgres.
Ответ заключается не просто в том, чтобы «добавить больше индексов»; для целей этого вопроса, пожалуйста, предположите, что мы знаем, как настроить нашу базу данных.
Что помогло бы нам, если бы было возможно полностью контролировать процесс, с помощью которого ActiveAdmin собирает все параметры фильтра в конечную область. В частности, нам нужна возможность:
- Убедитесь, что диапазон даты и времени, указанный в параметрах фильтра, находится в пределах допустимых границ (и для отображения усеченного диапазона во входных данных фильтра при следующем отображении индексной страницы).
- Примените определенный порядок / алгоритм к тому, как применяются области для построения более точно настроенного запроса, а не неупорядоченного бесплатного для всех, который используется по умолчанию в AA. Это не тот случай, когда мы хотим «бороться с планировщиком postgres», но в большей степени настраиваем способ, которым AA создает определенные запросы, чтобы предотвратить применение патологических комбинаций фильтров (или предупредить пользователя во флэш-методе, что им нужно уточнить свой запрос до чего-то более конкретного).
- Сохраните все другие соглашения AA, которые по-прежнему работают так же, как find , например, определение
index
блока со стандартным отображением таблицы; было бы неплохо продолжать использовать тот же фильтр DSL; все, что мы хотим переопределить, это сборку области ресурсов.
Я немного покопался, но, похоже, не могу найти верного способа заставить это работать. Есть какие-нибудь идеи?
Ответ №1:
«Полный контроль» может быть большой темой, но я бы начал с переопределения index и поиска параметра ‘q’, который отправляется из Filters :: ViewHelper. Проверьте параметры запроса и измените или удалите их, если запрос выглядит слишком дорогим.