Point in time support

[IzhakJakov]

According to the documentation scrolling is no longer recommended

However, I cannot find a way to use PIT with Go code.

[karmi]

Since search_after is part of the body, there is no special support for it in the package. In fact, the XKCD example uses it for loading results:

go-elasticsearch/_examples/xkcdsearch/store.go

Line 209 in 4b40206

b.WriteString(fmt.Sprintf(` "search_after": %s`, after))

[Anaethelion]

Same goes for PIT, you can generate a PointInTime with :

go-elasticsearch/esapi/api.xpack.open_point_in_time.go

Line 36 in 8eab6ab

type OpenPointInTimeRequest struct {

Once you've retrieved the Id, pass it into the body of your request.
Don't forget to close the PIT with the same Id if you don't need it anymore to avoid surprises with :

go-elasticsearch/esapi/api.xpack.close_point_in_time.go

Line 36 in 8eab6ab

type ClosePointInTimeRequest struct {

[mweibel]

Hi!
Just stumbled upon this as well and wondered why this issue got closed.

Is that how it's recommended to build search queries?
Passing it like the xkcdsearch example seems relatively ugly for me. If you have parameterized queries and/or possibly JSON encoding issues while working on it, it's harder than it should be to write code for it.

Besides, the go Search API has several functions to specify the search request but is missing some. Why is this the case? e.g. stored_fields or so go directly into the request body as well, no?

If that's not the way the API should be used, why is the Search API as is in the go library?
Maybe it needs a proper search query generator in this library?

[Anaethelion]

Hi @mweibel,

Thank you for these very interesting questions !
This issue has been closed because it was specifically about not finding the PointInTime API which, I believe, has been answered.

The current Go client is a "low-level" client and relies on json specification to generate it's API but avoids interfering with the body. Since the PointInTime API relies on the content of the body this should be handled by the user.
As per your example stored_fields are passed as Query parameters in the url and thus doesn't touch the body.

However, I believe what you are referring to is more of a helper which already has it's own issue here : #186

Please feel free to pitch in or raise another issue if that's not the case !

[mweibel]

@Anaethelion thanks for the answer (and sorry for the late reply).

However, I believe what you are referring to is more of a helper which already has it's own issue here : #186

Hmm not really. I was looking more for a search query builder or something like that. Because of the different fields in the Search Request struct I thought the Point in Time is just missing. But of course you're right - all the other fields can be passed as a query string as well. Didn't inspect the code so I didn't see it ;)

Given that the library is a low level client, I wonder if a search query builder could be part of this library or rather another library? I'd gladly raise an issue if you could imagine this.

[Anaethelion]

We are working on higher level clients and some form of query builder is definitely on the table !