Support rivers

[kxepal]

It would be nice to have support rivers feature. As far as I see it currently missed.

[kxepal]

If nobody minds, I'll start work on it since I need in CouchDB river support. And this raises a question: should aioes ship only generic river support, or also it should support specific rivers? Or only official ones? While they are almost shares the same API, few of them implements own specific bits.

[asvetlov]

Hi. I doubt that rivers should be part of aioes.
elasticsearch-py has no river api.
API is not well-structured. There is /_river/{river_name}/_meta, meta format is river-specific.

From my perspective better to have specific river support in separate library (using aioes transport of course, as standard aioes client does).
Think also about tests. For CouchDB river tests you need to install CouchDB and river on development box and fix travis CI script. Testing of twitter river may be even more complicated.

[kxepal]

That a strange bit for official client. For instance, pyes supports rivers.

I agree that API is too generic, but there are some common bits (as index definition and _meta) which could be used as base for others. If aioes tends to provide exactly the same API and feature set as elasticsearch-py, then probably I have to raise this question for them, right?

As about tests you're right: it would be hard to implement any functional tests without proper installed and configured environment. This makes me agree with you that different rivers have to be implemented in thirdparty projects.

[asvetlov]

@kxepal feel free to make third-party library on top of aioes. You really need only for Elasticsearch.transport for accessing to river API.