Did the Explain endpoint ever support search_type: dfs_query_then_fetch? If it does now (I'm on 7.1), how do I specify it?
I was thrown for a loop when using the Explain API on two identical documents, but seeing different score calculations. Learning the documents lived in different shards, and that the TF/IDF inputs were calculated per-shard explained the difference. Using dfs_query_then_fetch on the Search API normalized the scores, but the ElasticSearch .net client (both LowLevel and NEST) don't appear to expose a way to specify it for calls to the Explain API.
I also tried to form a request manually, passing it as a querystring or request body parameter. Both fail saying the argument is invalid. I thought perhaps the Explain endpoint didn't offer a way to specify dfs_query_then_fetch, but digging through some old issues it appears that it at least did at some point:
https://github.com/elastic/elasticsearch/issues/2612
Search type is not supported on the explain API. An approach that might work would be to use the Search API with dfs_query_then_fetch and explain, with a compound query that filters only to the document you're interested in (using IdsQuery), along with the query you want the explanation for.
Related
I'm new to the FHIR World, I have a FHIR client, HAPI FHIR that I can use to fetch data through a restful API. I apology if I missunderstand something during my FHIR documentation journey.
I've look around the documentation and tried some requests to fetch basic data, like a list of Patient, an Observation by id etc..
In my case, I need to get a list of Patient that have the same name as its resource generalPractioner (it's unlikely to happen, it's just an example).
In regular SQL it would look like something like this :
SELECT * FROM Patient
INNER JOIN Practitioner ON Practitioner.id = Patient.practitioner_id
WHERE Patient.name = Practitioner.name
Since FHIR doesn't work that way and isn't relational database, I need to come up with a way to do the equivalent of SQL's WHERE and SQL's JOIN but through the restful API of the client.
My questions are : Is it possible to do these kind of thing directly on a FHIR Client through the API ? If yes, do I need to make new modules inside HAPI FHIR (JPA or plain server ?) (using Java) so it can understand what I really want ?(a new parser with a new route on each resource for example).
Note that the example with the SQL query is pretty simple, my project is to be able to do really nested joins and wheres, as well as the SQL's AND and OR. It doesn't have to use graphQL, this is just what matches the most with my idea while I was reading the documentation.
I'm afraid that regular _include, _filter and _search parameters aren't enough for what I need.
I found that the fhirpath thing could be use but I didn't find how to use it through the API (except with the $graphql operation).
Seems like ChatGPT want me to use the operation $fhirql which is no longer supported in the recent versions of HAPI FHIR, this seemed to be wnat I want.
Thanks !
I do not know what $fhirql is - and I think I know everything there is to know about FHIR. And Google comes up blank, so that might be ChatGPT just fantasising again. Maybe it invented that based on https://github.com/FirelyTeam/FhirQuery, which is clearly the kind of thing you're thinking about.
Or maybe Pathling is closer to what you want: https://pathling.csiro.au.
$graphql only lets you filter your data, it doesn't allow de novo new joins. _filter is the nearest to what you want, for the few servers that support it, but even then, no joins the way you want.
So it looks like you'll have to fetch the data from your API by a client, and then do something locally, which is how those tools work. Unless the server does something specific for you
I'm new to the elastic-cloud interface. It allows to chooose operations get, post, put and del. I'm trying to submit queries, but I don't know the precise syntax. For instance:
tweet/_search?q=something
works, but:
tweet/_search?q={ "match_all": {} }
does not, returning a parser error. I have tried with double quotes, but it seems that then it searches for the query as a string.
The preferred way to test the search APIs are using the POST method, GET API in some case, gives even incorrect search results as it ignores the search and brings the top 10 search results for match_all query.
Elasticsearch supports both methods GET and POST to search but using the GET method which has payload information isn't common on modern app-severs, although Elasticsearch implemented it requires carefully crafting your queries.
Still, if you want to use the GET API, then for complex queries its better to send it as part of request body, I know it sounds weird to send a body to GET request but it works 😀 .
I'm trying to create a small app that displays some simple visualizations from data indexed on Elasticsearch (on an AWS managed Elasticsearch service).
Since, to the best of my knowledge, the degree of access control that AWS offers over its ES service is based on allowing specific HTTP verbs (GET, POST, etc), to simplify my life and the ES admin's, I'm granting this app "read only" permissions, so only GET and HEAD.
However, I see that for its search API, ES exposes a GET endpoint that works with query string parameters, and a POST endpoint that works with a JSON based "Query DSL". This DSL seems to be the preferred method in all examples I have seen online and in the books.
Given the predominance of the Query DSL throughout the documentation, I was wondering:
Does the the Query DSL exposes functionality that standard query string parameters don't, or are they both functionally equivalent?
Does the POST search endpoint result in any data being actually POSTED, or is this only a workaround to allow to send JSON as a query that breaks a little bit with REST conventions?
As per the docs
You can use query parameters to define your search criteria directly in the request URI, rather than in the request body. Request URI searches do not support the full Elasticsearch Query DSL, but are handy for testing.
The GET behavior is slightly confusing but even Kibana sends a POST in the background when you perform a GET with a body. If you have to use GET, some query results might be unexpected. What's your exact use case? Which queries are we talking?
FYI more useful info is here and here.
This is an example resource tree.
I need to retrieve latest 48 hours' data of cnt-2 and cnt-0 all together. What kind of query string should I put to the request ?
/in-cse
/in-cse/ae-123
/in-cse/cnt-2
/in-cse/cin-21
/in-cse/cin-22
/in-cse/cin-23
/in-cse/ae-124
/in-cse/cnt-0
/in-cse/cin-01
/in-cse/cin-02
/in-cse/cin-03
/in-cse/cnt-1
/in-cse/cin-11
/in-cse/cin-22
/in-cse/cin-33
Where should I put the ids of cnt-0 and cnt-2 in the querystring ?
/onem2m/api/v1/~/in-cse?fu=2&crb=20190808T000000&cra=20190806T000000&ty=4
Also should I use only querystring to make discovery or is it valid to make a POST request ?
With the example request in your question you will also get all the matching <contentInstance> resources of cnt-1, because you do the discovery on the level of the IN-CSE. Unfortunately, you cannot have multiple targets in a single request, but I see at least two solutions that could work for your use case:
You can add labels two <contentInstance> resources and add label to your search.
/onem2m/api/v1/~/in-cse?fu=2&crb=20190808T000000&cra=20190806T000000&label=myLabel&ty=4
You can add a <group> that contains the <container> resources that are important to your use case (ie. cnt-0 and cnt-2) and make the <group>'s fanoutPoint the target of your discovery request. The CSE is then responsible to redirect the discovery to each member of the <group>.
/onem2m/api/v1/~/in-cse/aGroup/fopt?fu=2&crb=20190808T000000&cra=20190806T000000&ty=4
In my opinion the second method is the more "elegant" one because it makes the (application) relationship of the two <container> resources clearer , but the first one might also be feasible if your <contentInstance> resources are tagged using labels anyway.
Regarding the POST request: For the HTTP binding query parameters are only allowed for filtering and discovery. Please have a look at TS-0009, section 6.2.2.2 Query component.
Btw, there are currently ongoing discussions in oneM2M to describe the differences between retrieval and discovery a bit better.
I need to boost the score of a match based on a field that is not searched on. ElasticSearch lets you do it using "custom_filters_score". I am using NEST API and I am not sure if this is supported or if there is an alternative to this? The documentation is not very helpful on this aspect.
http://nest.azurewebsites.net/query/custom-filters-score.html
Is there a way using NEST querying API other than falling back on RawQuery?
A pull request for this has been send for this: https://github.com/Mpdreamz/NEST/pull/237
Which will make it into the next release.