First timer: good first impression

[ToshY]

Hey @alexander-schranz 👋

Just came across this library and after a quick look at the docs, this library looks like you've spend a good amount of time and effort in creating it 👏 Seems to fit a lot of (my) various needs, so I immediatly wanted to try it out.

Backstory: I've been using Meilisearch (and its PHP library) for a couple of weeks now, but I was looking for something that fits better with Symfony (6.4), as their own implementation with Symfony is currently limited to just entity indexing.

Now what I first noticed from the install is that I came across just one minor hickup. After following the Installation guide and installing the packages schranz-search/symfony-bundle and schranz-search/seal-meilisearch-adapter, I noticed it did not automatically add the SearchBundle to config/bundles.php.

config/bundles.php

<?php

return [
    Symfony\Bundle\FrameworkBundle\FrameworkBundle::class => ['all' => true],
    // Had to manually add the SearchBundle
    Schranz\Search\Integration\Symfony\SearchBundle::class => ['all' => true],
];

This is not a big deal, and I'm not sure if it's something I messed up during the install, but it's something I wanted to point out 🙂

Overall, setting up the config, creating a schema with provider, and also running the (re)indexing commands really work great! Also, the documentation is easy to follow with a lot of examples, which I really appreciate 👍

---

So after the indexing I tried to rewrite some of my "raw" filters to the new Conditions, and at a certain point I stumbled across an issue: I'm using OR operators in my filters, but where's the OrCondition 🤔

An example (raw) filter which I'm currently using is as follows:

(start.Year >= 2000 OR start.Year IS NULL) AND (end.Year <= 2024 OR end.Year IS NULL)

For me, this raises several questions:

1. There doesn't seem to be an existing OrCondition, so how should I approach this?
2. As the filter also uses IS NULL, how would use this if none of the Conditions allow for type null to be passed as value?
3. While this 1 filter actually could be broken down to 2 separate filters/conditions, it begs the question if there's a possiblity to nest multiple conditions.

In pseudo-code I would imagine having nested conditions like this to rewrite the raw filter above:

AndCondition(
    OrCondition(
        GreaterThanEqualCondition(start.Year, 2000), 
        IsNullCondition(start.Year)
    ), 
    OrCondition(
        LessThanEqualCondition(end.Year, 2024), 
        IsNullCondition(end.Year)
    )
)

As you can see I'd like to have some extra conditions like AndCondition, OrCondition, IsNullCondition, etc. And while I thought that doesn't sound like a bad idea, I honestly don't know what kind of impact that would have to add those. So with that said, I thought of a simpler idea: something like a RawFilterCondition, which allows (like the name suggests) the raw filter you want to add.

Schranz\Search\SEAL\Search\Condition\RawFilterCondition

<?php

declare(strict_types=1);

namespace Schranz\Search\SEAL\Search\Condition;

class RawFilterCondition
{
    public function __construct(
        public readonly string $value,
    ) {
    }
}

Schranz\Search\SEAL\Adapter\Meilisearch\MeilisearchSearcher

<?php
        // inside the `search` method

        $filters = [];
        foreach ($search->filters as $filter) {
            match (true) {
                $filter instanceof Condition\IdentifierCondition => $filters[] = $index->getIdentifierField()->name . ' = ' . $this->escapeFilterValue($filter->identifier),
                $filter instanceof Condition\SearchCondition => $query = $filter->query,
                $filter instanceof Condition\EqualCondition => $filters[] = $filter->field . ' = ' . $this->escapeFilterValue($filter->value),
                $filter instanceof Condition\NotEqualCondition => $filters[] = $filter->field . ' != ' . $this->escapeFilterValue($filter->value),
                $filter instanceof Condition\GreaterThanCondition => $filters[] = $filter->field . ' > ' . $this->escapeFilterValue($filter->value),
                $filter instanceof Condition\GreaterThanEqualCondition => $filters[] = $filter->field . ' >= ' . $this->escapeFilterValue($filter->value),
                $filter instanceof Condition\LessThanCondition => $filters[] = $filter->field . ' < ' . $this->escapeFilterValue($filter->value),
                $filter instanceof Condition\LessThanEqualCondition => $filters[] = $filter->field . ' <= ' . $this->escapeFilterValue($filter->value),
                // Add this extra case; not sure if `escapeFilterValue`, maybe `$filter->value` is enough to keep it really raw
                $filter instanceof Condition\RawFilterCondition => $filters[] = $this->escapeFilterValue($filter->value),
                default => throw new \LogicException($filter::class . ' filter not implemented.'),
            };
        }

I then should be able to do something like this:

$searchBuilder = $this->engine->createSearchBuilder();
$searchBuilder->addIndex('awesome')
    ->addFilter(RawFilterCondition('(start.Year >= 2000 OR start.Year IS NULL) AND (end.Year <= 2024 OR end.Year IS NULL)'))
    ->getSearch();

---

Another thing I'm actually looking for (is something I was also missing in the Meilisearch bundle itself) is the possiblity to freely add and remove filters.

The use case is as follows:

• Let's say I have free and paid content, of which guests can view the free content and (logged-in) users can view both free and paid content.
• I can easily check if a user is logged in or not, so with that in mind I want to create a SearchBuilder that takes this into account by creating an instance which which always performs an addFilter(...) call for the index I'm going to search the content for.
• Now if I'm using this specific SearchBuilder the filter is always applied by default. Great, exactly what I was looking for, as I now don't have to add addFilter every time I'm going to use it in my services.
• However, at certain parts of the application I want to keep using this same specific SearchBuilder but I explicitely want this filter removed now.
• Hmm... 🤔

I've been thinking on how to approach this, and while I could create different SearchBuilder instances for the same index, one with and one without having the filter added by default, that doesn't really seem efficient in more complex cases when there's a need for multiple default filters to be added.

So my initial idea was to add a removeFilter method (maybe even a removeSortBy while we're at it) to the SearchBuilder.

Schranz\Search\SEAL\Search\SearchBuilder

<?php

declare(strict_types=1);

/*
 * This file is part of the Schranz Search package.
 *
 * (c) Alexander Schranz <alexander@sulu.io>
 *
 * For the full copyright and license information, please view the LICENSE
 * file that was distributed with this source code.
 */

namespace Schranz\Search\SEAL\Search;

use Schranz\Search\SEAL\Adapter\SearcherInterface;
use Schranz\Search\SEAL\Schema\Index;
use Schranz\Search\SEAL\Schema\Schema;

final class SearchBuilder
{
    /**
     * @var array<string, Index>
     */
    private array $indexes = [];

    /**
     * @var object[]
     */
    private array $filters = [];

    /**
     * @var array<string, 'asc'|'desc'>
     */
    private array $sortBys = [];

    private int $offset = 0;

    private ?int $limit = null;

    public function __construct(
        readonly private Schema $schema,
        readonly private SearcherInterface $searcher,
    ) {
    }

    public function addIndex(string $name): static
    {
        $this->indexes[$name] = $this->schema->indexes[$name];

        return $this;
    }

    public function addFilter(object $filter): static
    {
        $key = serialize($filter);
        $this->filters[$key] = $filter;

        return $this;
    }

    public function removeFilter(object $filter): static
    {
        $key = serialize($filter);
        if (array_key_exists($key, $this->filters) === true) {
            unset($this->filters[$key]);
        }

        return $this;
    }

    /**
     * @param 'asc'|'desc' $direction
     */
    public function addSortBy(string $field, string $direction): static
    {
        $this->sortBys[$field] = $direction;

        return $this;
    }

    public function removeSortBy(string $field, string $direction): static
    {
        if (array_key_exists($field, $this->sortBys) === true) {
            unset($this->sortBys[$field]);
        }

        return $this;
    }

    public function limit(int $limit): static
    {
        $this->limit = $limit;

        return $this;
    }

    public function offset(int $offset): static
    {
        $this->offset = $offset;

        return $this;
    }

    public function getSearch(): Search
    {
        return new Search(
            $this->indexes,
            $this->filters,
            $this->sortBys,
            $this->limit,
            $this->offset,
        );
    }

    public function getResult(): Result
    {
        return $this->searcher->search($this->getSearch());
    }
}

I then should be able to do something like this:

$searchBuilder = $this->engine->createSearchBuilder();
$searchBuilder->addIndex('awesome')
    ->removeFilter(LessThanEqualCondition('end.Year', 2024))
    ->getSearch();

To me this seems like a very small addition which allows for a lot more flexibility.

Another idea, but I think that's more Symfony specific, would be to use something like events/subscribers/listeners. I honestly don't have much experience with this, but I can imagine it's possible to create custom events and subscribing to those to manipulate the filters. Just pointing it out.

---

Let me know what you think of it, If the above suggestions don't sound too far-fetched, I'm willing to create feature requests with corresponding PRs for it 🙂 If you think it may be better to leave out of the schranz-search that's fine too; I will extend the existing searchers with my own logic then 👌

[alexander-schranz]

@ToshY First I really want to thank you for giving SEAL a try and give here feedback. I try to answer all your questions.

Now what I first noticed from the install is that I came across just one minor hickup. After following the Installation guide and installing the packages schranz-search/symfony-bundle and schranz-search/seal-meilisearch-adapter, I noticed it did not automatically add the SearchBundle to config/bundles.php.

Symfony Flex normally should automatically find the Bundle class and register it. Still we could improve the installation process for Symfony users providing a symfony recipe. I created an issue for this, recipes need to be contributed to the symfony recipes repository. The issue on our side can be found here: #316, if you contribute this let me know in the linked issue.

AndCondition, OrCondition

This two are planned to be supported but currently I first need todo a research how to achieve it correctly in the different search engines. But it sure something which will come in one of the future versions of SEAL.

Please feel free to upvote: #317

IsNullCondition

I did not yet think about this one as not in all search engines something like null does exists. I'm not even yet sure if I for example indexing multi values like in the test example "tags": ["Tag A", "Tag B"] and we would add here support for null via "tags": ["Tag A", null, "Tag C"], its sure more technical not a real world example. But maybe something like a IsEmptyCondition make sense. This would be keep in mind that "title": "" and "title": null at the end would be the same.

Feel free to add your thoughts to: #318 and upvote it.

RawFilterCondition

This is something I want not to add at current state but want to add in future maybe. At current state I'm required to get great feedback like this to know where the limits of SEAL are and what people expect from a search library. Adding things like RawFilterCondition people would always workaround at current state via it and I would not really get feedback about what is missing in the current library.

So my initial idea was to add a removeFilter method

I'm not planning to add a removeFilter method. Once a filter is added it will not be able to remove it at current state. What should be supported is that you can ue clone $searchBuilder for a deep clone of the existing conditions and then in case A you add then additional filters or others filters then in case B.

I Hope I could answer all your questions.

Best Regards,
Alex

[ToshY]

Thank you for the detailed explanations 🙂 I will check out the issues/features you've created and see if I can add some valuable ideas to them.

[alexander-schranz]

Thank you for give SEAL a try and create such great feedback where you see the limitations. 😃