according to the docs, it is possible to do source filtering on the returned document beginning with elasticseach 1.0.0beta
I tried all the examples from the url below, but the source is always completely returned.
Also, when sending _source:false, the whole document is still returned as well.
Is this a known issue?
http://www.elasticsearch.org/guide/en/elasticsearch/reference/master/search-request-source-filtering.html
found the solution. Needed to use POST instead of PUT
Related
I created a Kibana dashboard, containing some visualization. I can successfully embed the dashboard using the provided url:
{url}/app/kibana#/dashboard/{dashboard_uuid}?embed=true&_g=(refreshInterval:(display:Off,pause:!f,value:0),time:(from:now-1y,mode:quick,to:now))
Now, I would like to have any user of my app to see this dashboard, filtered in order to only see their data. The filter query that I need is very simple, because all the data contains a field user_id.
An example: For the user with identifier $id, I want to load the dashboard with the filter user_id:$id
In there a way to set the filter through the url? I see there are some parameters already (refreshInterval, time..) but I couldn't find the proper documentation. Any ideas?
Using Kibana 6.2.2 and ElasticSearch 6.6.0
I tried setting the filters through the _a parameter, as explained here: https://discuss.elastic.co/t/dashboard-search-parameter-via-url/84385 without success.
{url}/app/kibana#/dashboard/{dashboard_uuid}?
embed=true&
_g=(refreshInterval:(display:Off,pause:!f,value:0),time:(from:now-1y,mode:quick,to:now))&
_a=(filters:!(),query:(querystring:(query: "user_id:1")))
I stumbled upon this while looking for a solution to a slightly similar question. I figured I would share two options that I have gotten to [mostly] work, but either should do what you are looking for.
URL With Variable Set to Application State:
../app/dashboards#/view/{dashboard_uuid}?_a=(filters:!((query:(match_phrase:(user_id:$id)))))
Using this method, the filter is not "pinned", so if you have another link on your landing dashboard, the filter will not remain if you click that link. However, your other global state settings (timeframe, etc.) do remain.
URL With Variable Set to Global State:
../app/dashboards#/view/{dashboard_uuid}?_g=(filters:!((query:(match_phrase:(user_id:$id)))))
Using this method, the filter is "pinned" and remains throughout additional clicks. However, this URL will overwrite all your other global state settings (timeframe, etc.).
This is where I am. I would like the filter to remain pinned, but if I have a time filter set as well, clicking this link will unfortunately default to the timepicker:timeDefaults setting in Kibana.
I still have not found a solution to my issue, but I hope this answers the original question; or perhaps help someone else that stumbles here (seeing as how this thread is very old now).
Learning from here: List attachments and Use query parameters
When I call v1.0/me/messages/{message id}/attachments/?$filter=isInline eq true.
It returns both inline and not inline.
When I call v1.0/me/messages/{message id}/attachments/?$filter=size gt 15000.
It returns attachments with all sizes, included for example 14000.
It just ignores the filter parameter...
Is this correct? Documentation says nothing about that.
Is there another way to get only the inline attachments with one query?
There is a known bug with the /attachments endpoint affecting support the $filter clause.
You can track the status of this issue at GitHub. I've also added a reference to your question here.
I'm facing some problem regarding to query hit for generating suggestion.
Please take a look below URL structure and suggest the appropriate URL modification.
http://{host-name}/search?start=0&num=1000&site=bhtest&output=xml&client=pp_frontend&filter=0&getfields=*&q=sken+inmeta:contenttype~Product%20OR%20inmeta:contenttype~Content
In the above query, search term is "sken", GSA suggestion tag should appear and provide suggestion for "skin" but it is not happening
When I change the query to:
http://{host-name}/search?start=0&num=1000&site=bhtest&output=xml&client=pp_frontend&filter=0&getfields=*&q=sken
Then it provides the suggestions.
Can you please help to find out the problem in first one URL.
Suggestions are not returned when you add metadata filters. See the search protocol reference found here
The way to work around this is to issue two queries, one with your filter and one without.
It is related to language parameter in my oppinion. Try use &lr and &hl parameters. GSA suggest by this parameters.
Is there any method on elasticsearch for fully (not partially) updating documents and not create new ones in case it doesn’t already exists?
Until now, I found that the _update method, while passing a doc attribute inside the json request body to partially updating documents, however, I would like to replace the entire document in this case, not only partially.
I have also found that, the index method, where sending a PUT request works fine, although creating a new document in case the id not yet indexed.
Setting the op_type parameter to create will enforce document creation instead update.
I was wondering if there is any way to always enforce update and never create a new one?
Or perhaps is there another method that would allow me to achieve such task?
If I understand correctly, you want to index a doc, but only if it already exists? Like an op_type option of update?
You can mostly do it with the update API, given that your mapping remains consistent. With an _update, if the document doesn't exist, you'll get back a 404. If it does exist, ES will merge the contents of doc with whatever document exists there. If you make sure you're sending over a new doc with all the fields in the mapping, then you're effectively replacing it outright.
Note, however, that you can do it without the document merge rather efficiently in two requests; the first one checking for doc existence with a HEAD request. If HEAD /idx/type/id is successful, then do a PUT. This is essentially what's happening internally anyway with the update API, with a little extra overhead. But HEAD is really cheap because it's not shuffling any payload around. It simply returns an HTTP 200/404.
We use the Result format (from the Search Protocol) for our results page (we manually parse the XML responds). We wishes now to switch to the Dynamic Result Clusters format. The only problem is that spelling suggestion (Related Queries) doesn't seem to be available using that protocol.
The only solution I seem to find is to:
First do a /clusters... request. If the request return no result...
...to another request to /search... to see if that request would return a spelling suggestion (Related Queries).
Am I missing something? Can the Clusters format return also spelling suggestion?
Got it.
/clusters request are not to be use instead of the /search request.
You must :
First, do a normal /search request.
Then, do a AJAX request to /clusters to produce the suggestion.
So you keep all the features of the /search request (KeyMatches, Related Queries, etc).