removing Search::Elasticsearch #64
Conversation
mickeyn
force-pushed
the
mickey/wip_remove_ses
branch
from
d3d9c06
to
19cc83f
Compare
| size => 1000, | ||
| body => $body, | ||
| %{ $params }, | ||
| my $scroller = MetaCPAN::Client::Scroll->new( |
|
I think this is a good idea. S::Es is a huge complex module and we don't really need that complexity. |
mickeyn
force-pushed
the
mickey/wip_remove_ses
branch
from
19cc83f
to
56e7b94
Compare
| @@ -347,5 +337,5 @@ Fetches a path from MetaCPAN (post or get), and returns the decoded result. | |||
|
|
|||
| =head2 ssearch | |||
|
|
|||
| Calls an Elastic Search query (using L<Search::Elasticsearch> and returns an | |||
| L<Search::Elasticsearch::Scroll> scroller object. | |||
| Calls an Elastic Search query and returns an L<MetaCPAN::Client::Scroll> | |||
There was a problem hiding this comment.
s/Elastic Search/Elasticsearch/
mickeyn
force-pushed
the
mickey/wip_remove_ses
branch
from
56e7b94
to
6c2f964
Compare
|
@oalders AFAIK |
Created an internall scroller for the client. We only use this one feature (scrolled searches) and we have it as a dependency to function as an API to an API we could just use directly. The motivation is the breaking changes in latest 5.x versions of Search::Elasticsearch and the fact it's incompatiable with the current client code.
mickeyn
force-pushed
the
mickey/wip_remove_ses
branch
from
6c2f964
to
f69c112
Compare
|
|
|
Oh, and for the record, I discussed this topic with @mickeyn, and I support it too. |
|
Type::Tiny works fine on 5.24, but fails its tests on 5.26. We're working on getting that resolved though. |
|
@oalders please check the latest changes, added type checking. hope it's what you meant. |
|
@mickeyn looks good to me. Bonus points for creating a type library! |
|
i'll follow @haarg's advice and convert it to use |
mickeyn
force-pushed
the
mickey/wip_remove_ses
branch
from
63d55d3
to
60eb8ae
Compare
#55 and other complaints regarding this issue convinced me we got to get rid of the S::Es usage (we only use it for scrolled searches) - it's a pain and its current (and probably future) breaking changes will only make it even more of a nightmare.
As I see it, while we don't upgrade to it, we have some users (+testers) having issues with it. if we do, we open a can of worms and will have to support all issues people will have with it (we will have to force them to upgrade, as the same code doesn't work on both 2.03 and 5.x).
I figured it's just an API to an API to I'm using the destination one directly here.