RT
хотя тоже так себе решение
Size: a a a
2019 September 05
АС
как вариант использовать все таки Filter не как dto, а возложить на него обязанность билдинга этих самых критериев в момент вызова read
тогда теляется другая задумка, что фильтр финальная сущьность
АС
для использования в гридах и апи
RT
ну я за то чтобы он и был расширяемым
RT
для использования в гридах и апи
почему для использования в гридах он должен быть финальным?
AM
final можно жертвовать
AM
я верно понял?
АС
ну я за то чтобы он и был расширяемым
учитывая что что он на вход получает array, ты так и не выдал примера зачем это может быть нужно
AM
FilterInterface {
public function build();
}
и далее есть
Filter
ArrayFilter
SQLFilter
public function build();
}
и далее есть
Filter
ArrayFilter
SQLFilter
AM
и так далее
AM
вопрос: что будет на выходе build?
AM
public function read(): iterable
{
$data = $this->data;
if ($this->filter !== null) {
$data = $this->filter->build($this->data);
}
...
}
{
$data = $this->data;
if ($this->filter !== null) {
$data = $this->filter->build($this->data);
}
...
}
И нет, вот так не выйдет. Контрольная проверка:
SQL-табличка на 5 млн. записей.
SQL-табличка на 5 млн. записей.
AM
То есть главный принцип, который рушить ну никак нельзя: сначала формируем критерий, потом его применяем к запросу. Это касается и сортировки, и фильтрации и limit и offset.
АС
То есть главный принцип, который рушить ну никак нельзя: сначала формируем критерий, потом его применяем к запросу. Это касается и сортировки, и фильтрации и limit и offset.
ну чисто теоретически с фильтрами можно поступить как с пагинатором, хотя и мне не особо нравится. чтоб у него был метод read который оборачивает dataReader
AM
нельзя
AM
разве тогда получится применить фильтр к самому запросу, а не постфактум к 5 млн. записей?
RT
учитывая что что он на вход получает array, ты так и не выдал примера зачем это может быть нужно
я же вроде писал, что это нужно просто для того чтобы оставить пользователю возможность его заменить
типа:
final class UserFilter implements FilterInterface
{
private $user;
public function __construct(User $user)
{
$this->user;
}
public function getCriteria(): array
{
return [
'user_id' => $this->user->id,
];
}
}
$dataReader->withFilter(new UserFilter($user));
типа:
final class UserFilter implements FilterInterface
{
private $user;
public function __construct(User $user)
{
$this->user;
}
public function getCriteria(): array
{
return [
'user_id' => $this->user->id,
];
}
}
$dataReader->withFilter(new UserFilter($user));
АС
разве тогда получится применить фильтр к самому запросу, а не постфактум к 5 млн. записей?
да, limit и offset же применяются
АС
разве тогда получится применить фильтр к самому запросу, а не постфактум к 5 млн. записей?
хотя всетаки согласен что с реализацией будет хуже чем в идее с queryBilder