i am running a grouped query in the latest go sdk ...
# community-help
b
i am running a grouped query in the latest go sdk and are seeing some strange numbers for out_of. Fetched challenge candidates info found=1809 page=1 outOf=180291 i am fetching page1 there are 1809 total hits and 180k pages? this is my query
Copy code
params := &api.SearchCollectionParams{
		Q:             "*",
		QueryBy:       "owner",
		FilterBy:      StringPointer(fmt.Sprintf("number.play_id:%s", ids)),
		IncludeFields: StringPointer("number.play_id,update_at,owner"),
		GroupBy:       StringPointer("owner"),
		PerPage:       IntegerPointer(250),
	}
Maybe I can optimize my query as well, what i am looking for here is to fetch all owerns that owns all of the plays i send in. so if i send in 1,2,3 the owner has to atleast own 1 of each play_id to be a hit. right now I am just doing the rest of the logic in golang, but doing it in lower layers is always better mechanical sympathy wise
k
Have you tried making a raw curl request to see if that matches?
Out of here means total number of results
b
i have not tried raw curl no
but paged works with groups but outOf not?
k
i.e.
out_of
is total number of documents in the collection, and this is ungrouped count.
b
ok it says “the total number of pages” in the comment
so it looks like it is a documentation bug then
k
My bad, that's a typo error
Must be a copy paste error
b
do you want me to file an issue?
k
Yes, thanks
b
the code is generated from openApi it looks like. what repo do you want the issue in? i do not think typesense-go is relevant?
k
why not just contribute and save you the work
k
Thank you! I will update and publish the go client with this change shortly.
b
amazing!
btw have you considered adding a method to the typesnse-go client that just fetches all pages if things are paged?
k
Can you elaborate what you mean by "all pages"?
b
if the searchResult has more then one page then fetch the rest in a convenience method
i have it now myself, so not a big one for me, just wondered
maybe it is best just to leave that code in userland
i can see lots of different strategies for parallelization and error handling
k
The client is currently a very thin wrapper around the API but open to adding such convenience methods.
b
ok
will consider it if the use case emerges
👍 1