Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Official client usage #1275
There is old story about implement elasticsearch-php as foundation of Elastica #944
Also as some proposals, that stuck in "client-transport-connection" layer problem, that can't be easy solved.
But we can already use official client benefits without waiting solution for transport layer. I suggest make first step not from solving transport layer, but from starting usage Endpoints.
This PR shows how official client can be used right now, for example for Stats endpoint.
Great timing about this PR as I wanted to look into this issue once again. This is an awesome improvement!!!
I suggest we split this PR into two parts:
- Introduce the requestEndpoint method
- Switch of existing stats to using the official client endpoints
The first one is a no brainer for me. For the second one I trying to understand what the long term benefit will be as it makes a few things more complicated. Don't get me wrong that I think we should not do the second part of the change, just trying to understand more about it.
@ruflin will do requested changes and will split PR later at evening
Long term benefit is that it will be easy to follow elasticsearch changes. For example for Stats endpoint. With usage endpoint from official client Elastica doesn't know anything about is this GET or POST request, and what is a "path" for this endpoint. This mean that if something will be changed there, it is just enough to update in composer official client requirement version and it will be work. This information already in official client, why not to use it and reduce maintenance costs for Elastica codebase?
Same for another endpoints. Official client Endpoints have validation of params "checkUserParams" and so on, that also gives advantages, as for Elastica developers, as for end-user. This will make life easier to follow elasticsearch changes. Update version, and check what is broken.
And which one thing it makes more complicated?
Fully agree on your points. The one I was referring to was this one here: https://github.com/ruflin/Elastica/pull/1275/files#diff-b94c222b7bfe828e265627016909c3adR105 The reason is that it requires to add the index which happened before "magically" in the
An other good thing about using endpoints as you started to do in this PR is I think in the long run, we will not need our own request method anymore and will fully depend on the base client request layer.
@ruflin I get your point about add requestEndpoint to Type and Index, when I prepare PR, I was thinking on it too. The problem there, that in this case we will change Endpoint object inside Elastica code, that is kindly unexpected by developer who use Elastica. Another solution clone Endpoint object and then "setIndex", this looks much better, and I think it is cheap. I'm on position, that in all places where now we have "request" method, must be requestEndpoint method.
yes, later Client::request can be even deprecated, if we will see that it is not needed anymore. For now it is too early for me to say that it is needed. Maybe good idea to not deprecate it, since some users will have cases that require really "raw" queries and don't want make custom Endpoint.
Ok, I drop changes in Stats and Status and left only changes for request.
What I want to add, it is throwing exception:
And same for type.
But for this we need elastic/elasticsearch-php#557
So, what do you think?