I have certain fields named accordingly: attr_name, attr_type, ... and I want them all embedded in the hits layer of the vector tile.
After reading the docs, I would form the body as follows with a wildcard.
{
"fields": ["attr_*"]
}
However that returns none of the fields. What am I doing wrong?
You are not doing anything wrong, unfortunately it seems to be a bug and wildcards are not working in this API. I have opened an issue to address it:
https://github.com/elastic/elasticsearch/issues/85592
Related
Given the following GQL
query getMembers {
repository(owner: "nasa", name: "cumulus") {
mentionableUsers(first: 100) {
nodes {
login
organization(login: "nasa") {
login
}
}
}
}
}
(Query against GitHub v4 GraphQL)
the value for login under organization is either "nasa" or null
I am trying to figure out if it's possible to use #skip against the login/organization so that only contributors to the repo, who are members of the nasa org are shown. I believe for this particular query you can do it another way, but this is just an example.
How would you use #skip/#include with a non boolean. There is minimal documentation on this. While I could filter the response JSON in my client side app, it would be more efficient to receive less data sent over the network and then to parse in my app.
Playing in GraphQLi I received errors trying this various ways - maybe its only possible if the field returns a boolean itself?
e.g., I couldn't do login #skip(if login==null). I also tried setting a value to null in the variables section and the referencing it in the query, but none of the variations I tried work.
What I would really like to do is not include the parent if the child field is some value. e.g., if login=null then don't include that mentionable user. There is no search field option on mentionableUser. From my reading, I am guessing that the only way to do this would be if the API was modified to put a search or filter field on the mentionalbeUsers, otherwise I would need to do this with my client?
Couple of points.
Both the #skip and #include directives provide the same functionality -- allowing the client to arbitrarily chose whether a field should be included in the request.
Let's say we have a query like:
query ($skipBar: Boolean!) {
foo
bar #skip(if: $skipBar)
}
If I set skipBar to true, I am effectively just sending this query:
query {
foo
}
If I set it to false, I am effectively just sending this query:
query {
foo
bar
}
As a client, my logic has to determine the value to assign to skipBar, but I could just as easily use that same logic to decide between sending one of those two queries. In other words, like variables and fragments, #skip and #include are simply a convenient way to keep things DRY on the client-side. They cannot be used to filter the result returned by the server.
GraphQL syntax does not support expressions (or for that matter, any sort of references to parts of the response). Additionally, #skip and #include only take a single argument (if) and that argument must be passed a Boolean -- either as a variable or as a literal value. Even if you could somehow pass an expression to the if argument, though, the directives determine whether the field is included in the request, period. So if the skipped field is part of a returned List (like a List of nodes), it will be absent from every node when it's skipped.
So, is there a workaround?
Not really :( As you've already guessed, if the GitHub API doesn't provide a way to filter a field, there's not much you can do as a client -- you'll have to apply the filtering logic client-side.
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 am doing a file.list in the google drive api
GET https://www.googleapis.com/drive/v3/files?access_token=XXXX
This is working fine but its only returning four fields for each of the files in the list
"kind": "drive#file",
"id": "1x8-vD-XiXEEA5Spf3qp8x2wltablGF22Lpwup8VtxNY",
"name": "Experts Activity Dump go/ExpertsActivities",
"mimeType": "application/vnd.google-apps.spreadsheet"
The documentation states that it should be returning a full file resource for each file but its not.
The only thing i have been able to do is to do a file.get on each of the files to get additional information.
This was an old issue that appears to have been fixed now.
GET https://www.googleapis.com/drive/v3/files?fields=*&access_token=XXXX
by sending fields=* you can now see a full file.resorce response for each of the files in the list. It is no longer necessary to do a file.get for each file.
That being said its probably a good idea to limit the fields to those you actually need
This is the intended behaviour of the API. For reference, you may see here the explanation next to the "fields" parameter:
The paths of the fields you want included in the response. If not specified, the response includes a default set of fields specific to this method. For development you can use the special value * to return all fields, but you'll achieve greater performance by only selecting the fields you need. For more information see the partial responses documentation.
For this api, the default fields are indeed kind, id, name and mimeType.
It is recommended that you limit the fields (using the aforementioned parameter) to the ones you need, as it will yield a considerable performance difference.
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
I'm having a problem getting a couchdb view to return the proper documents when using multiple keys.
This works fine, returning the documents that match:
GET http://example.com:5984/myDb/_design/myFilters/_view/getItemByForeignKeyId?key=abc123
This returns returns all documents in the view, matching or not:
GET http://example.com:5984/myDb/_design/myFilters/_view/getItemByForeignKeyId?keys=%5B%22abc123%22%5D
I'm usually very good at hunting down my answers. But, CouchDB documentation is very clear on the format for using multiple keys. I've seen some use the ?keys=[123,123] and i've also seen ?keys="abc","abc".
If anyone can offer any clarification on the 'proper' format and encoding of multiple key queries for CouchDB using a GET method, I would be extremely appreciative.
To get multiple keys from a view, you need to do a post request and submit the keys in the request body. Your HTTP request will look like this:
POST /myDb/_design/myFilters/_view/getItemByForeignKeyId
Content-Type: application/json
{
"keys" : [
"abc",
"123"
]
}
function(doc){
{
if([doc.key1, doc.key2])
emit([doc.key1, doc.thingYouWantToKnow]);
}
}
and in the query string, at the end
?key=["key1Value", "key2Value"]
Notice that it is key=[], not keys=[] !!!!!!!!!
Not saying it's correct, but you can actually do it via query string as well. The array enclosing brackets should not be encoded. E.g. this works for me:
http://localhost:5984/test/_design/artists_albums/_view/albums_by_artist?keys=[%22Super%20bad%20artist%22,%20%22Fake%20artist%201%22]