Share Button

Read the English version

Elasticsearch est capable d’indexer d’énormes volumes de données, aussi bien des documents que des chiffres.
Dans les versions inférieures à la v1.0.0, les facettes permettaient de récupérer des statistiques pour une liste de documents indexés (répartition par tag, moyenne, écart-type,…)
Au fil du temps, l’utilisation de ces facettes a évolué. Les développeurs ont souhaité s’en servir pour réaliser des statistiques de plus en plus poussées.
En réponse à cela, la géniale équipe Elasticsearch a ajouté l’implémentation des agrégations :
- Métriques : Somme, minimum, maximum, moyenne, ….
- “Buckets” : Répartition par terme, par date, par valeur, … Ces agrégations peuvent contenir des sous-agrégations. On peut donc calculer des statistiques dans une répartition par terme, un truc de malade!

Le but de cet article est de décrire une des utilisations qui peuvent être faites de ces agrégations : des statistiques.

Continue reading

Share Button

Share Button

Lire la version française

The XML configuration for FOSElasticaBundle is powerful, but in some cases this is not enough.
In order to solve this, FOS allows you to override the transformation from Doctrine Object to an ElasticSearch Document : ModelToElasticSearchTransformer.

Continue reading

Share Button

Share Button

Lire la version française

When and why hydrating objects thanks to Transformers?

When you use Elasticsearch and the FosElasticaBundle Finders, the responses received from Elasticsearch are automatically transformed into Doctrine objects.

In some cases, you will need to display some information that come from a join : a photo, a category translation, …
Unfortunately, the hydratation is only done on the objects : FosElasticaBundle transforms the ids that match your search into objects via a select * in (:ids).
The consequence is that, for each entry in your results list, Doctrine will make a query for the join object (for example a Category). For 100 results in 100 different categories, 100 simple queries will be done. You understand what can happen with a complex model and several joins.

Fortunately, you can avoid that by overriding the Transformer.
Continue reading

Share Button

Share Button

Read the English version

La configuration XML du FOSElasticaBundle est très performante. Il existe quelques rares cas ou cela ne s’avère pas suffisant.

Pour résoudre ce problème, FOS permet de surcharger la transformation entre un Objet Doctrine (ORM ou ODM) et un Document ElasticSearch : le ModelToElasticaTransformer.

Continue reading

Share Button

Share Button

Read the English version

Dans un système de données non relationnel, ce qui peut manquer ce sont les jointures.
Heureusement, Elasticsearch propose des solutions pour répondre à différents besoins :

Array Type

Lire l’article sur elasticsearch.org

Comme son nom l’indique : ce peut être un tableau de types natifs (string, int, …) mais aussi d’objets (c’est la base utilisée pour les “objects” et les “nested”).
Continue reading

Share Button

Share Button

Read the English version

Quand et pourquoi hydrater son objet avec les Transformers?

Quand on utilise Elasticsearch et les Finders du FOSElasticaBundle, les réponses reçues d’Elasticsearch sont automatiquement transformées en objets Doctrine. 

Dans certains cas, vous aurez besoin d’afficher une information issue d’une jointure : la photo, la traduction d’une catégorie, …
Malheureusement, l’hydratation est faite uniquement sur les objets en question : FOSElasticaBundle transforme les ids correspondant à la recherche en objets via un select * in (:ids).
Conséquence : pour chaque entrée dans votre liste de résultats, Doctrine ira chercher la Category associée. Pour 100 enregistrements dans 100 catégories différentes, 100 requêtes simples seront ajoutées. On se rend compte de ce qui peut arriver avec un modèle de données compliqué et plusieurs jointures.

Heureusement, pour éviter cela, vous pouvez surcharger le Transformer.
Continue reading

Share Button

Share Button

Read the English version

Cet article présente comment configurer et rechercher avec Elasticsearch sur un projet Symfony :

Continue reading

Share Button

Share Button

Read the English version

Cet article est le deuxième d’une série consacrée à Elasticsearch.
Il n’a pas pour but de présenter ce qu’est Elasticsearch, vous pourrez en lire plus par exemple sur ce blog : http://blog.zenika.com/index.php?post/2012/11/14/Premiers-pas-avec-ElasticSearch-Partie-1. Mais il vous permettra de mettre les mains dans le moteur, et de comprendre les articles qui suivront.
Continue reading

Share Button

Share Button

Read the English version

Comme nous avions besoin d’une connexion entre une application web Symfony et une appli Android, nous avons dû apprendre et comprendre comment créer une API Rest de manière simple et sécurisée, en nous basant sur nos entités existantes.

Nous avons choisi WSSE pour l’accès sécurisé, FOSRestBundle pour la restitution de données et JMSSerializerBundle pour la sérialisation. 

Nous avions également besoin de séparer les logs pour les erreurs d’authentification WSSE. Lisez notre article pour savoir comment créer un fichier de logs séparé avec Monolog (en anglais).

Continue reading

Share Button

Share Button

Lire la version française

As REST needs to be stateless :

The client–server communication is further constrained by no client context being stored on the server between requests. Each request from any client contains all of the information necessary to service the request, and any session state is held in the client.

Wikipedia Rest Article

We needed to add a new authentication provider in symfony2 in accordance with this constraint. We chose WSSE.

This article describes how to configure WSSE, how to mix it with FOSRestBundle and how to test it with Google Chrome.
Continue reading

Share Button