I am running a kibana query from postman. Exact same query in Kibana Discover tab returns 49 rows of records. But, in postman, i can only see few results.
I can see hits as 49 but the array does not contain 49 elements.
"hits": {
"total": {
"value": 49,
"relation": "eq"
},
"max_score": 0.0,
I found the answer.
"size": 500,
should be added above the query field. It returns all the values
Related
I'm using firebase firestore using Rest API to get data limited by 5 documents only, ordered by a field called LikesCount.
When I want to fetch the next 5 documents I have to use startAt and pass the LikesCount value of the last document from the first 5 documents.
But in this way, it will fetch wrong data when there is another document with the same LikesCount value So I tried and searched a lot about how to pass the last Document id in addition to the LikesCount value But all of them did not work In addition, I tested the pagination using the Web SDK and it was working correctly because you can pass the document snapshot easily, but what does the document snapshot object include? So that we can understand the structure of the Cursor and apply it to the REST API.
I tried to use this method to pass the Document ID as referenceValue
{
"structuredQuery": {
"from": [{
"collectionId": "Users"
}],
"where": {
"compositeFilter": {
"op": "AND",
"filters": []
}
},
"orderBy": [{
"field": {
"fieldPath": "LikesCount"
},
"direction": "DESCENDING"
}],
"startAt":
{ "values": [
{
"integerValue": "6"
},
{
"referenceValue": "projects/myprojectid/databases/(default)/documents/Posts/xEvmJ1LLHwTKVREQfXtX"
}
],
"before": false
},
"limit":5
}
}
But an error will occur : Cursor has too many values.
also, I tried to pass only the referenceValue and it still did not return the correct 5 documents.
Thanks in advance :)
Your orderBy() has 1 field (LikesCount) but your startAt() has 2 fields. I suspect that is the reason for the error message?
Passing the integerValue won't work. If there are 13 results with the value 6, then each time you make the above call you'd get the same first 5 results.
When you say:
I tried only passing the referenceValue and still did not get the correct 5 documents
what documents are you getting? What documents were you expecting to get?
https://westus2.dev.cognitive.microsoft.com/docs/services/form-recognizer-api/operations/AnalyzeWithCustomModel
In the above documentation there is the following URL which implies you ought to be able to analyze a form for a specific Key value
https://{endpoint}/formrecognizer/v1.0-preview/custom/models/{id}/analyze[?keys]
I have trained a model of my own and when I use the Get Keys method this is what gets returned...
{"clusters":{"0":["House Name","Mobile Number","Name","Phone Number","Postcode","Street","Sumame","Town Name","e-Mail Address (required)"]}}
It seems to me that I ought to be able to execute that post against any one of those key values. So....
https://{endpoint}/formrecognizer/v1.0-preview/custom/models/{id}/analyze?keys=Name
Should pull back whatever the value is associated with the Name key (and there is a value) but instead I get a 200 success and no workable information.
"status": "success",
"pages": [
{
"number": 1,
"height": 756,
"width": 471,
"clusterId": null,
"keyValuePairs": [],
"tables": []
}
],
"errors": []
}
I think I am misunderstanding how to do this properly
Are you able to see the key and an associated value when you try the /analyze call without the query param "keys"?
Attempting to hook up a trigger from Zapier when a Firestore document gets added, Zapier asks for an orderBy element. Documentation (https://zapier.com/help/firebase/#creating-a-firestore-structured-query-for-a-trigger) seems pretty straightforward, but I get an error that
ERROR: We had trouble finding a sample. The specified query does not contain valid JSON. Unexpected token } in JSON at position 123
I tried a couple of variations (see below for 2 examples), but I keep getting the same error each with a different position.
"orderBy": [{
"field": {
"fieldPath": "timestamp"
},
"direction": "DESCENDING"
}],
(Result: Position 123)
"orderBy": [{
"field": "timestamp,
"direction": "DESCENDING"
}],
(Result: Position 46)
I'm not even sure where Zapier is getting the JSON, so I can't look at the JSON to see if anything is funky.
Does anyone know how to fix, or at least how to view the full JSON file?
The issue is the trailing comma after the last ], which makes it invalid JSON.
Actually it's this one trailing comma, which renders the query invalid: ]},} - that should be ]}}.
The full JSON can usually be downloaded in the Firebase console; at least for Realtime Database.
And when it complains about JSON syntax, just use JSONLint; most IDE also highlight syntax errors.
According to Zapier documentation:
"orderBy": [{
"field": {
"fieldPath": "someKeyOfYourChoice"
},
"direction": "DESCENDING"
}]
This worked for me. There are more cases of troubleshooting, I highly suggest to check the site out if you still experiencing some issues:
https://zapier.com/help/doc/common-problems-firebase#creating-a-firestore-structured-query-for-a-trigger
I've stubled upon an issue for updating order line items' metadata via WooCommerce REST API using node.js.
I've been following these steps for updating orders (and was succesful with some fields):
https://woocommerce.github.io/woocommerce-rest-api-docs/#update-an-order
Now, what I would like to achieve is changing the number of shipped line items of an order. Something I would normally use the partial orders WC plugin in the wordpress UI.
Below, you can find a screenshot of a line item I get from WC using the orders API call. The last element of the meta_data array has key 'shipped' and it contains an array with one object, stating that one (out of two ordered items) had been shipped:
"line_items": [{
"id": 1937,
"name": "Maya",
"product_id": 1271,
"variation_id": 1272,
"quantity": 2,
"tax_class": "",
"subtotal": "140.00",
"subtotal_tax": "0.00",
"total": "140.00",
"total_tax": "0.00",
"taxes": [],
"meta_data": [{
"id": 21637,
"key": "pa_product-color",
"value": "beige"
}, {
"id": 21638,
"key": "pa_shoe-size",
"value": "42"
}, {
"id": 21639,
"key": "pa_shoe-width",
"value": "wide"
}, {
"id": 21640,
"key": "shipped",
"value": [{
"qty": 1,
"date": "Nov 21, 2017"
}
]
}
],
"sku": "2522BE42W",
"price": 70
},
As you can see, the value of the key 'shipped' is an object. When I ty to send it (back) to WC, I get an error saying:
"data":{"status":400,"params":{"line_items":"line_items[0][meta_data][3][value] is not of type string."}}}
When I try to send the value as a string, i.e.
lineItems[0].meta_data = [{key:"shipped", value: "[{qty:'2'}]" }]
I get no errors, but WC treats this as string, not as an object and doesn't update the shipment qty in the DB the way I intended (it only pulls the shipped quantity down to 0 instead):
{
"id": 21640,
"key": "shipped",
"value": "[{qty:'2'}]"
}
Any insights or ideas - how could I modify the shipped quantity of line items via the WC API?
So, apparently there was a bug in WP 4.9 version, which was fixed recently in the following commit:
https://github.com/woocommerce/woocommerce/pull/17849
It concerns REST API schema and after merging the fix to WooCommerce, the problems disappear and now I am able to send the data as an object.
More on the topic can be found here:
https://github.com/woocommerce/wc-api-dev/pull/74
I'm doing some early trials on Cosmos, and populated a table with a set of DTOs. While some simple WHERE queries seem to return quite quickly, others are horribly inefficient. A simple COUNT(1) from c took several secons and used over 10K request units. Even worse, doing a little experiment with ordering also was very discouraging. Here's my query
SELECT TOP 20 c.Foo, c.Location from c
ORDER BY c.Location.Position.Latitude DESC
My collection (if the count was correct, I got super weird results running it while populating the DB, but that's another issue) contains about 300K DTOs. The above query ran for about 30 seconds (I currently have the DB configured to perform with 4K RU/s), and ate 87453.439 RUs with 6 round trips. Obviously, that's a no-go.
According to the documentation, the numeric Latitute property should be indexed, so I'm not sure it's me screwing up here, or the reality didn't really catch up with the marketing here ;)
Any idea on why this doesn't perform properly? Thanks for your advice!
Here's a document as returned:
{
"Id": "y-139",
"Location": {
"Position": {
"Latitude": 47.3796977,
"Longitude": 8.523499
},
"Name": "Restaurant Eichhörnli",
"Details": "Nietengasse 16, 8004 Zürich, Switzerland"
},
"TimeWindow": {
"ReferenceTime": "2017-07-01T15:00:00",
"ReferenceTimeUtc": "2017-07-01T15:00:00+02:00",
"Direction": 0,
"Minutes": 45
}
}
The DB/collection I use is just the default one that can be created for the ToDo application from within the Azure portal. This apparently created the following indexing policy:
{
"indexingMode": "consistent",
"automatic": true,
"includedPaths": [
{
"path": "/*",
"indexes": [
{
"kind": "Range",
"dataType": "Number",
"precision": -1
},
{
"kind": "Hash",
"dataType": "String",
"precision": 3
}
]
}
],
"excludedPaths": []
}
Update as of Dec 2017:
I revisited my unchanged database and ran the same query again. This time, it's fast and instead of > 87000 RUs, it eats up around 6 RUs. Bottom line: It appears there was something very, very wrong with Cosmos DB, but whatever it was, it seems to be gone.