I am also very interested in helping to build a kotlin-friendly API for elasticsearch (although rubberband does work fine so far), if you are looking for help.

The DSL can build queries dynamically, you can do whatever Kotlin you want in the middle, around, pass pieces around, etc

I’ll take a look at RubberBand as well, thanks! and contributors are always welcome, let me get to first working model and then will be easier to see where people can help.

cool. that would be the most important bit for my current use cases (the dynamic query building)

the versioning issue: are you intending to build static models of the different versions?

I’m not quite sure yet, going to investigate differences over time to see what types of changes have happened. If it is just additions, deprecations, deletions, and not real structural changes all the time then we can just API diff and deprecate and version tag things.

yeah that would be very interesting to know in order to make any sane decision

@vmironov has left the channel

@seunoh has left the channel

@yasyd has left the channel

@mplatvoet has left the channel

I wonder if Kotlin could provide suitable tools to operate as a new scripting language. 😮

@fellshard: I think the intent of the Elastic team is to narrow down to just their new scripting language and not take the risk on others. Almost any other has been problems for them in the past. And the new one is functional enough.

Hi, just noticed this slack channel. I also created a thin DSL wrapper around the java elasticsearch client: https://github.com/mbuhot/eskotlin The idea was that translating the JSON from my interactive session in marvel/sense into the equivalent java was not straight-forward. So I created a DSL that mimics the JSON query dsl as closely as possible.

@mbuhot: nice!

We are waiting on this project until seeing the Elasticsearch 5 new changes to the client, which I believe is going to be REST only now

and then decide what to do for Kotlin-izing it

for a DSL we would still like to code generate it from the Sense / API spec files and not hand code so we do not have to keep up with every change they do in the future.

REST-only? So no more transport client?

@jkwatson has left the channel

Is there a spec for the querydsl? After some googling I found some JSON descriptions of the api, but it just described the query object generically.

@mbuhot: in the sense plugin source code is information in JSON format that describes the query DSL

for Estatik we pull it, merge it with the REST API spec and create a unified tree

@apatrida: Sounds awesome. So the final API will feel close to the JSON querydsl / make it easy to move from an interactive sense session into kotlin code.

@fboldog has left the channel

@matthewdias has left the channel

@mesquka has left the channel

@kz has left the channel

@Petros Paraskevopoulos has left the channel