New entry for wiki (documentation): no hydration

[Badlapje]

I want to use this bundle to search using ES, but keep a Doctrine-managed sql-database as the main record store. To increase performance i don't want to hydrate results of a search via Doctrine. A use case that - through searches on stack overflow (but also the issues here) - i've found is not uncommon. Sadly though, the docs do not offer any explanation as to how one can pull this off. I would therefore like to issue this pull request to amend the wiki to make this clear (via a cookbook entry).

I'm quite alright with writing something up for the wiki, but i want to ensure i have my facts straight first (setting me in the right direction for some of these questions would be enough, i can try it out on my own project and use code from there to illustrate the concepts when writing the wiki entry).

How to turn off hydration?

I found a reference in the issues about setting hydrate to false (see #568), but i don't know where? Is this supposed to go under the settings for the index? Like so:

indexes:
    %elasticsearch_index%:
        finder: ~
        settings:
            index:
                analysis:
                    analyzer:
                        nl_analyzer:
                            type: snowball
                            language: Dutch
            hydrate: false

Does the above also mean that i can use the finder without the results getting hydrated?

Searching without hydration via using the fos_elastica.index_manager and creating a search from an index.

If i understand the entry about multi-type search correctly, then it's possible to search without hydrating (regardless of how the hydrate setting is set) by doing the following in my Controller:

$mngr = $this->get('fos_elastica.index_manager');

$search = $mngr->getIndex('app')->createSearch(); $search->addType('article'); $search->addType('news'); $resultSet = $search->search($query);

The above is off course assuming that i've set the index name to app. Questions that arise for that method are:

• can i search the entire index by omitting the addType declarations? That seems to be implied by the explanation in the multitype search entry, but it's not stated outright.
• suppose i want to perform another search right after but that time only for article types and not for news types. Do i need to: a. remove the news type (and does that happen like so: $search->removeType('news'))? b. create a new search from the manager and/or index and add the article type there (meaning i can reuse the manager to make a second search with it's own type)? c. get a new manager and from there a new search? I'm assuming the answer will be a or b. It would be interesting to know whether a single manager/index can have multiple searches associated with it (as that'd provide options to create a utility searching class for the application).

  Using a custom transformer to avoid hydration?

Can i somehow create a custom transformer to transform elastica results into Objects of the corresponding entities (for use in twig and whatnot), without hydrating them. Meaning i wouldn't need to set hydration to false but i could actually write a custom transformer for any object i want to avoid being hydrated.

• if so: what are the things i need to take in mind to accomplish this? I found this article which has an implementation of a transformer to use when there's a nested object. Can this approach be amended to transform the results into models without hydrating? Eg. something like this:

    foreach ($values as $key => $value) {
        if (!is_null($value))
        {
            $entity->{"set".$key}($value);
        }
    }

Where $entity is a new instance of the correct model and the $values the returned (and decoded) json holding the result for a single type. (the above is of course assuming no values need to be handed to the constructor to instantiate a new object.

I may have forgotten or overlooked things above, so if i did: please kindly point out the direction i need to search.

[skonsoft]

@Badlapje thank you very much for this topic. Using standard implementation of this bundle is a bad thing. For each Elastic search query, i got a dozen of doctrine queries too. I don't undrestand why we have enabled Hydratation by default. The right way is to disable it and if we need it, we can just enable it.

I hope that maintainers fix this problem for next releases.

[bitgandtter]

Not only that it should be enabled by default but also it should not query database at all. Right now no matter if hydrate its enabled or not it always query database it only dont hydrate the objects after database query but the main aim here is to avoid extra connections to the database.

[luzzardi]

Has someone found a solution for that issue?

[Badlapje]

I implemented my own query class of the ES store (which bypasses the hydration but it's an ugly fix really), i still have this on my list to contribute a fix to it when i have time (hoping over the summer i will).

[raspberryman]

+1