Ā As you might remember Lukas and I started working on some changes to the elastica library and the Symfony 2 Bundle FOQElasticaBundle during a hackday. You might also remember that we were not entirely happy with our solution for the infinite nesting levels in the mappings configuration of the bundle. Also, we got some feedback from other developers upon our pull requests to both the library and the bundle. In order to be able to clean up our code and respond to the feedback I asked for some innovation budget and got it. Thanks for that! :)

So, what did I do exactly with this budget:

Elastica

During the hackday we enhanced the elastica library with serializer support so you could not just pass data arrays to it to be written to the elasticsearch index, but also whole objects that then will be serialized and written to the index. At first we simply passed a serializer object to the library, assuming it has a public method called ā€˜serialize'. We also added support for serializer groups, taking the example of the JMSSerializer.

After some discussion with other developers and the maintainer of the library we decided that it would be a better solution to just pass a PHP callable to the library. This gives the developer the possibility to use whatever serializer he/she likes and to configure it properly.

The pull requestĀ for these changes was already merged to the master branch of the library.

At the same time I also adapted the FOQElasticaBundle to give the developer the possibility to make use of this new serializer support of the elastica library. I also implemented a default serializer callable using the JMSSerializer. This pull request is at the moment still waiting for feedback.

FOQElasticaBundle

Another change we did to the FOQElasticaBundle during the hackday was to try to add support for an infinite number of nesting levels in the mapping configurations. The solution we found then was working but there were some drawbacks about it. e.g. the error messages given to the developer when using a wrong value for a certain configuration variable were not clear because with that solution we didn't find a way to generate the full path to the wrong variable. We created a pull request anyways and could discuss some better solutions with other developers.

The solution we came up with in the end is the following. Instead of trying to build a configuration tree that accepts an infinite number of nesting levels in the mappings we generate a fix tree based on the current configuration. This means that we pass the configuration array to the DependencyInjectionConfiguration class and figure out based on the array, how many nested levels are necessary and which ones. Based on that we then build a fix configuration tree exactly matching the current configuration. Like that we also get the nice automatically generated error messages when passing a wrong value to one of the configuration variables.

The pull request is still waiting for feedback.