-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to use filters on index for additional searchparams/options #315
Comments
I think if considering this then it should more belong to https://github.com/meilisearch/meilisearch-symfony than to this repo |
Hey @norkunas 👋 As a Symfony user myself I'm okay with that, and I can recreate the issue there if needed (or maybe you can move it over there?). However, the initial thought of creating the issue in this repo was that Doctrine filters also aren't specific to Symfony. With that in mind, making a more generic implementation for filters would allow users that don't use Symfony to benefit from this feature as well. |
But those filters are specific to ORM while this library is more like DBAL because it's just an api client, that's why I think this way.
There are meilisearch api clients in many languages, so those wouldn't benefit as well |
I was referring to those are using this (PHP) library without Symfony framework: Laravel, Laminas, no frameworks, etc. In an attempt to convince you that it has a more righful place here, I've started tinkering on this myself yesterday and came up with a relatively easy setup to achieve what I'm looking for myself. In short, by overriding/extending the existing classes Starting with my sample project structure. App/
├── Filter/
│ └── Meilisearch/
│ └── FreeTierFilter.php
└── Service/
└── External/
└── Request/
└── Meilisearch/
├── Enum/
│ └── MergeAction.php
├── Filter/
│ ├── AbstractFilterInterface.php
│ ├── ArrayFilter.php
│ └── ScalarFilter.php
├── MeilisearchClient.php
├── MeilisearchHandlesIndexes.php
└── MeilisearchIndexes.php
From top-to-bottom here comes the implementation of these classes.
|
Hello thank you @ToshY for opening the issue |
Interesting. I put something together for being able to use ApiPlatform to filter on facets. It's complicated and not very elegant, but it works great. #[ApiFilter(FacetsFieldSearchFilter::class, properties: ['marking', 'locale', 'countryCode'])] When indexing, it searches the class attributes, and creates the settings that are passed to Meilisearch. $properties = $arguments['properties'];
foreach ($properties as $property) {
if (!array_key_exists($property, $settings)) {
$settings[$property] = [
'name' => $property,
'browsable' => false,
'sortable' => false,
'searchable' => false
];
}
switch ($filter) {
case FacetsFieldSearchFilter::class:
$settings[$property]['browsable'] = true;
break;
case SortFilter::class:
case OrderFilter::class:
$settings[$property]['sortable'] = true;
break;
case SearchFilter::class:
case MeiliMultiFieldSearchFilter::class:
case RangeFilter::class:
case MultiFieldSearchFilter::class:
$settings[$property]['searchable'] = true;
break;
}
}
} And eventually after some more tweaking $index = $this->meiliService->getIndex($indexName, $primaryKey);
$results = $index->updateSettings($settings) It looks like schranz-search handles this more elegantly. The schema is interesting, but ugh, yet another schema to figure out. Schema is probably a better word than settings, and filter v. search is also confusing at least initially. |
Description
I would like to the possibility to be able to create filters that would allow the
search
/rawSearch
methods to have additionalsearchParams
/options
from these filters.Basic example
Other
An example use-case for this is as follows:
freeTier
.freeTier = 1
is available for guests and authenticated users.freeTier = 0
is explicitly available for authenticated users.searchParams
which essentially would addAND (freeTier = 1)
filter.freeTier
values0
and1
.Now if similar, but not exact same, searches are performed on the same index, I'd still like it to take into consideration this
freeTier = 1
field without manually concatenating this filter to every place a search on this index is performed. But with that in mind, if for some reason it is not desired to use the filter at a certain search, I should also have the possibility to disable/enable at any time.The feature request boils down to a kind of Doctrine filters functionality for the Meilisearch search methods.
The text was updated successfully, but these errors were encountered: