# Query Proxying **URL:** \ **Category:** Elasticsearch\ **Created:** [October 7, 2010, 4:18pm UTC](https://discuss.elastic.co/t/query-proxying/3421 "2010-10-07T16:18:06Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![mooky](https://avatars.discourse-cdn.com/v4/letter/m/43a26b/32.png) [@mooky](https://discuss.elastic.co/u/mooky)\ **Post date:** [October 7, 2010, 4:18pm UTC](https://discuss.elastic.co/t/query-proxying/3421/1 "2010-10-07T16:18:06Z")
Hi all, Does anyone have some suggestion as to how to best achieve the proxying of an elasticsearch query in Java? We are currently building the query in the javascript client, and we want to pass this query to a server which will use the java api to execute the query (and do something with the results). We don’t really want our server to understand the query or how to build it again. Just some way of constructing the query from a string (json or uri), or a map... -Mooky ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [October 7, 2010, 4:59pm UTC](https://discuss.elastic.co/t/query-proxying/3421/2 "2010-10-07T16:59:11Z")
The SearchRequestBuilder#setQuery, it accepts both a string (the json query) and byte. If you want to pass the full search request json (including facets, sorting, highlighting), then you can construct a SearchRequest, and initialize its source (byte, Map, ...). When using SearchRequest directly, you will need to use client#search API and not client#prepeareSearch. -shay.banon On Thu, Oct 7, 2010 at 6:18 PM, the claw [nick.minutello@gmail.com](mailto:nick.minutello@gmail.com) wrote: > Hi all, > > Does anyone have some suggestion as to how to best achieve the > proxying of an elasticsearch query in Java? > > We are currently building the query in the javascript client, and we > want to pass this query to a server which will use the java api to > execute the query (and do something with the results). > > We don’t really want our server to understand the query or how to > build it again. Just some way of constructing the query from a string > (json or uri), or a map... > > -Mooky ---
**Author:** ![mooky](https://avatars.discourse-cdn.com/v4/letter/m/43a26b/32.png) [@mooky](https://discuss.elastic.co/u/mooky)\ **Post date:** [October 7, 2010, 7:53pm UTC](https://discuss.elastic.co/t/query-proxying/3421/3 "2010-10-07T19:53:54Z")
Excellent. Thanks. A little bit more about what we are thinking of doing - maybe you have some suggestions on how best to approach what we are trying to do: We are indexing a number of documents that represent differences/ changes : e.g. something like { "resourceType" : "spot", "resourceId" : "0005.HK", "differenceType" : "CHANGE" // could be NEW or REMOVED ... // more stuff } We display a list of these differences/changes to the user - with search/facets/filtering/sort/etc. Sometimes there are only a small number of diffs (10's) - sometimes there are 10's of thousands - and we paginate/filter the results (user sees a small window onto the data set). The UI (html/javascript) currently hits Elasticsearch directly & renders the results. The user has some interaction with this data - accepting or "holding" each change/diff. In some cases, the user will do this 1 by 1 - in other cases, in bulk (they might want to accept/hold all changes, or all changes of a particular type, or all changes matching the filtered view they are viewing at the time... whatever) When they accept/hold a change, we need to keep track of this state on the server and we also have to display to the user their selection choice alongside the data (changes) they are viewing. The question is how to "join" this data (the change and the user's choice) 1. we could store the user's choice in the index - which would mean doing an "update" on each document (or many documents) when the user makes/alters a choice. Its nice and simple because the UI hits elastic to get all the data it needs to render - nice and fast. Its unpleasant because it means a lot of "updates" (re-indexing) of documents... (unless there is a nice way to do this?) e.g. { "resourceType" : "spot", "resourceId" : "0005.HK", "differenceType" : "CHANGE" ... // more stuff "gating" : "ACCEPTED" // or HELD } 2. we could store the user's choice in memory on the server (in a map). That option is nice because its extremely fast & simple to update. Its unpleasant because we now have two sources of data that we need to display and we have to somehow "join" them. Is there any seamless way to hook into elastic so that we can inject data to augment the results? ie register a callback handler that gets called on each SearchHit (and some way of storing/retrieving extra data on the hit itself) -Nick On Oct 7, 5:59 pm, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote: > The SearchRequestBuilder#setQuery, it accepts both a string (the json query) > and byte. If you want to pass the full search request json (including > facets, sorting, highlighting), then you can construct a SearchRequest, and > initialize its source (byte, Map, ...). When using SearchRequest directly, > you will need to use client#search API and not client#prepeareSearch. > > -shay.banon > > On Thu, Oct 7, 2010 at 6:18 PM, the claw [nick.minute...@gmail.com](mailto:nick.minute...@gmail.com) wrote: > > > Hi all, > > > Does anyone have some suggestion as to how to best achieve the > > proxying of an elasticsearch query in Java? > > > We are currently building the query in the javascript client, and we > > want to pass this query to a server which will use the java api to > > execute the query (and do something with the results). > > > We don’t really want our server to understand the query or how to > > build it again. Just some way of constructing the query from a string > > (json or uri), or a map... > > > -Mooky ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [October 7, 2010, 7:59pm UTC](https://discuss.elastic.co/t/query-proxying/3421/4 "2010-10-07T19:59:22Z")
The option of updating that in elasticsearch is problematic for two reasons, the first is that as far as I understand, that decision is transient and has not been "committed", the second is that elasticsearch is not full real time. Storing the state on the server is another option, and then you need to either merge it on the server, or simply merge it on the client side. On the client side, I mean that the response will include the search response, but also a json with "id" -\> "changed state". Then, merging the results in javascript is much simpler than merging it on the java end... . -shay.banon On Thu, Oct 7, 2010 at 9:53 PM, Mooky [nick.minutello@gmail.com](mailto:nick.minutello@gmail.com) wrote: > Excellent. Thanks. > > A little bit more about what we are thinking of doing - maybe you have > some suggestions on how best to approach what we are trying to do: > > We are indexing a number of documents that represent differences/ > changes : > e.g. something like > { > "resourceType" : "spot", > "resourceId" : "0005.HK", > "differenceType" : "CHANGE" // could be NEW or REMOVED > ... // more stuff > } > > We display a list of these differences/changes to the user - with > search/facets/filtering/sort/etc. > Sometimes there are only a small number of diffs (10's) - sometimes > there are 10's of thousands - and we paginate/filter the results (user > sees a small window onto the data set). The UI (html/javascript) > currently hits Elasticsearch directly & renders the results. > > The user has some interaction with this data - accepting or "holding" > each change/diff. In some cases, the user will do this 1 by 1 - in > other cases, in bulk (they might want to accept/hold all changes, or > all changes of a particular type, or all changes matching the filtered > view they are viewing at the time... whatever) > > When they accept/hold a change, we need to keep track of this state on > the server and we also have to display to the user their selection > choice alongside the data (changes) they are viewing. The question is > how to "join" this data (the change and the user's choice) > > 1. we could store the user's choice in the index - which would mean > doing an "update" on each document (or many documents) when the user > makes/alters a choice. Its nice and simple because the UI hits elastic > to get all the data it needs to render - nice and fast. Its unpleasant > because it means a lot of "updates" (re-indexing) of documents... > (unless there is a nice way to do this?) > e.g. > { > "resourceType" : "spot", > "resourceId" : "0005.HK", > "differenceType" : "CHANGE" > ... // more stuff > "gating" : "ACCEPTED" // or HELD > } > > 2. we could store the user's choice in memory on the server (in a > map). That option is nice because its extremely fast & simple to > update. Its unpleasant because we now have two sources of data that we > need to display and we have to somehow "join" them. > Is there any seamless way to hook into elastic so that we can inject > data to augment the results? ie register a callback handler that gets > called on each SearchHit (and some way of storing/retrieving extra > data on the hit itself) > > -Nick > > On Oct 7, 5:59 pm, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote: > > > The SearchRequestBuilder#setQuery, it accepts both a string (the json > > query) > > and byte. If you want to pass the full search request json (including > > facets, sorting, highlighting), then you can construct a SearchRequest, > > and > > initialize its source (byte, Map, ...). When using SearchRequest > > directly, > > you will need to use client#search API and not client#prepeareSearch. > > > > -shay.banon > > > > On Thu, Oct 7, 2010 at 6:18 PM, the claw [nick.minute...@gmail.com](mailto:nick.minute...@gmail.com) > > wrote: > > > > > Hi all, > > > > > Does anyone have some suggestion as to how to best achieve the > > > proxying of an elasticsearch query in Java? > > > > > We are currently building the query in the javascript client, and we > > > want to pass this query to a server which will use the java api to > > > execute the query (and do something with the results). > > > > > We don’t really want our server to understand the query or how to > > > build it again. Just some way of constructing the query from a string > > > (json or uri), or a map... > > > > > -Mooky ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 4:18am UTC](https://discuss.elastic.co/t/query-proxying/3421/5 "2017-07-06T04:18:15Z")