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
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 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
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)
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
}
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 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 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
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 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)
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
}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 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
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
© 2020. All Rights Reserved - Elasticsearch
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant logo are trademarks of the Apache Software Foundation in the United States and/or other countries.