Implement elasticsearch-php as foundation of Elastica

[ruflin]

Elastica is a high level elasticsearch client, elasticsearch-php is a low level elasticsearch client. What both have in common are the low level implementations of connector, transport etc. Instead of trying both clients up to date with the newest improvements on these levels I suggest to take the elasticsearch-php client as the foundation of Elastica for the connection part to elasticsearch. This will bring together efforts to implement things like Guzzle and connection strategies.

As an approach for implementation I suggest to extend \Elastica\Client by \Elasticsearch\Client and make the \Elastic\Client use connection and transport form \Elasticsearch\Client. If possible backward compatibility for all request should not break.

The above will in addition allow every user of Elastica to use all low level functionality of the extended client in addition.

[xkidro]

+1 for this, I currently use the elasticsearch-php sdk but found that I need to implement high level functions myself :(

[ruflin]

@xkidro Good to hear. First I was thinking about introducing this with the es 2.0, but there are still quite a few open changes, so perhaps I will even prioritise this one higher. If you have some to help with this migration, that would be cool.

[CrAzE124]

+1 definitely, I haven't been on this repo for a while, and was just wondering whether this was possible. How can I help on this?

[ruflin]

@CrAzE124 My plan to implement this was as following, but because of 2.0 I didn't have the time yet to try it out.

• Elastica\Client should extend php-elasticsearch::Client
• At first, the only method that uses php-elasticsearch::Client is Elastica\Client::request(...).

The above would mean, php-elasticsearch has to be added to the composer file and the request method has to be adjusted so that it calls the php-elasticsearch client. At first, it doesn't even have to extend Elastica\Client.

The best help would be to try this out an open a pull request with these changes so we can discuss it on actual code.

[merk]

@ruflin I've been hitting issues with FOSEB which aren't worth fixing and prompt me to start over. Where are you at with this change? Is it still on the radar?

I dont really want to start from scratch on a dependency of Elastica if Elastica is going to move to become a value add on top of the official client, I'd prefer to support both from the get go.

[ruflin]

@merk This is definitively still on the radar. Unfortunately it seems like @CrAzE124 and @ewgRa both didn't find the time yet to progress on this one. Let me see if I find a way to push this change in faster.

Interesting to hear about FOSEB. Is it something that changed in Elastica or on the elasticsearch side? Would be interesting to hear more.

[merk]

The biggest pain point right now is the hard BC breaks from 2.x to 3.x of Elastica - given you move your required ES version with each release, we cant maintain support for ES1.7 (or any other release version) without maintaining multiple branches - coupled with a low test coverage and removal of features in Elastica 3 its unlikely or very hard to support both in one code branch.

Fundamentally, I'm not willing to break support for older versions unless there is a very real and important reason to, and since FOSEB is only using the most basic features of Elastica, it doesnt make sense to track your latest versions only.

[merk]

And I think the biggest pain point moving forward is managing index and transformation metadata. There is no generic method for defining this information, and the way we're handling it now is fragile and prone to breakage. I still havent been able to work out a decent enough solution. #810

[ruflin]

@merk It would be great if we could discuss the above points in an audio / video chat to go into more details. Let me know if you would be interested in having this direct conversation. I just sent you an email with my email :-) In case someone else would like to join the conversation, drop a message here.