Hi I am creating documents with commit like this way:
{
"writes": [
{
"update": {
"name": "projects/projectID/databases/(default)/documents/test/?documentId=",
"fields": {
"comment": {
"stringValue": "Hello World!"
}
}
}
},
{
"update": {
"name": "projects/projectID/databases/(default)/documents/test/?documentId=",
"fields": {
"comment": {
"stringValue": "Happy Birthday!"
}
}
}
}
]
}
The parameter ?documentId= dosen´t work like when creating a single document, if I left empty I get an error that I must specify the name of the document so how I can generate an automatic id for each document?
Unfortunately, batch commits with auto generated documentId are not possible in the Firestore REST API. As you can see in this documentation, the Document object should be provided with a full path, including the documentID:
“Name:string
The resource name of the document, for example projects/{project_id}/databases/{databaseId}/documents/{document_path}.”
And if it was possible to omit the documentID, it would be mentioned in this documentation.
If you would like to have this implemented in the Firestore REST API, you can create a feature request in Google’s Issue Tracker so that they can consider implementing it.
I just came across the same problem and discovered that it is still not implemented.
I created a feature request for it here: https://issuetracker.google.com/issues/227875470.
So please go star it if you want this to be added.
Related
My aim is to reduce the json file size, which contains the base64 image sections of the documents by default.
I am using the Document AI - Contract Processor in US region, nodejs SDK.
It is my understanding that setting fieldMask attribute in batchProcessDocuments request filters out the properties that will be in the resulting json.
I want to keep only the entities property.
Here are my call parameters:
const documentai = require('#google-cloud/documentai').v1;
const client = new documentai.DocumentProcessorServiceClient(options);
let params = {
"name": "projects/XXX/locations/us/processors/3e85a4841d13ce5",
"region": "us",
"inputDocuments": {
"gcsDocuments": {
"documents": [{
"mimeType": "application/pdf",
"gcsUri": "gs://bubble-bucket-XXX/files/CymbalContract.pdf"
}]
}
},
"documentOutputConfig": {
"gcsOutputConfig": {
"gcsUri": "gs://bubble-bucket-XXXX/ocr/"
},
"fieldMask": {
"paths": [
"entities"
]
}
}
};
client.batchProcessDocuments(params, function(error, operation) {
if (error) {
return reject(error);
}
return resolve({
"operationName": operation.name
});
});
However, the resulting json is still containing the full set of data.
Am I missing something here?
The auto-generated documentation for the Node.JS Client Library is a little hard to follow, but it looks like the fieldMask should be a member of the gcsOutputConfig instead of the documentOutputConfig. (I'm surprised the API didn't throw an error)
https://cloud.google.com/nodejs/docs/reference/documentai/latest/documentai/protos.google.cloud.documentai.v1.documentoutputconfig.gcsoutputconfig
The REST Docs are a little more clear
https://cloud.google.com/document-ai/docs/reference/rest/v1/DocumentOutputConfig#gcsoutputconfig
Note: For a REST API call and for other client libraries, the fieldMask is structured as a string (e.g. text,entities,pages.pageNumber)
I haven't tried this with the Node Client libraries before, but I'd recommend trying this as well if moving the parameter doesn't work on its own.
https://cloud.google.com/document-ai/docs/send-request#async-processor
my $create_issue_json = '{"fields": { "project": { "key": "ABC" }, "summary": "summary for version 1", "description": "Creating an issue via REST API", "issuetype": { "name": "Minutes" }}}';
$tx1 = $jira_ua->post($url2 => json => decode_json($create_issue_json));
my $res1 = $tx1->res->body;
I try to create a jira issue of type Minutes but POST expects some fields which are not available in the issue of type Minutes. The below is the response.
{"errorMessages":["Brands: Brands is required.","Detection: Detection is required."],"errors":{"versions":"Affects Version/s is required.","components":"Component/s is required."}}
I also tried to fetch the schema using createMeta api but don't find any useful info. The below is the response from createmeta.
{"maxResults":50,"startAt":0,"total":3,"isLast":true,"values":[
{
"self":"https://some_url.com/rest/api/2/issuetype/1",
"id":"1",
"description":"A problem which impairs or prevents the functions of the product.",
"iconUrl":"https://some_url.com:8443/secure/viewavatar?size=xsmall&avatarId=25683&avatarType=issuetype",
"name":"Bug",
"subtask":false},
{
"self":"https://some_url.com:8443/rest/api/2/issuetype/12",
"id":"12",
"description":"An issue type to document minutes of meetings, telecons and the like",
"iconUrl":"https://some_url.com:8443/secure/viewavatar?size=xsmall&avatarId=28180&avatarType=issuetype",
"name":"Minutes",
"subtask":false
},
{
"self":"https://some_url.com:8443/rest/api/2/issuetype/23",
"id":"23",
"description":"Used to split an existing issue of type \"Bug\"",
"iconUrl":"https://some_url.com:8443/images/icons/cmts_SubBug.gif",
"name":"Sub Bug",
"subtask":true
}
]
}
It looks like there Jira Admin has added these as manadatory fields for all the issuetypes which I came to know after speaking with him. He has now individual configuration for different issue types and am able to create minutes.
I've managed to successfully checkout a file using the https://graph.microsoft.com/beta/drives/{driveId}/items/{itemId}/checkout
Now, I'd like to get the information about the user, who actually perform the checkout operation.
It's possible to check if the item is locked:
https://graph.microsoft.com/beta/drives/{driveId}/items/{itemId}?select=*,publication
However, according to DOCs, publication doesn't provide information about the checked user. Without information who locked the file is the whole checkin/checkout logic is useless.
This kind of information could be retrieved via the metadata for an item in a list as demonstrated below:
https://graph.microsoft.com/beta/sites/{site-id}/lists/{list-id}/items/{item-id}?expand=fields(select=CheckoutUserLookupId)
Once you get checkout user id (CheckoutUserLookupId field) , user details could be determined via the following endpoint:
https://graph.microsoft.com/v1.0/sites/{site-id}/lists('User Information List')/items/{CheckoutUserLookupId}
where CheckoutUserLookupId is the user id from the previous request
https://graph.microsoft.com/beta/sites/{site-id}/lists/{list-id}/items/{item-id} can't work with folders.
Anyway, drive endpoint "Allows access to the list as a drive" (according to MS Graph Docs). It works with folders as expected.
So I have
get the drive-id: /sites/${siteId}/drives
list root folder: /drives/{drive-id}/items/root/children?select=name,publication
if an item is locked, it's possible to list the activity on the item:
/drives/${idObj.driveId}/items/${idObj.fileId}?select=id&expand=activities
return list of actions:
"activities": [
{
"#odata.type": "#oneDrive.activityEntity",
"#odata.id": "https://xxxxxxxxxx/v2.0/oneDrive.activityEntity2a3649d6-2xxxxx",
"#odata.editLink": "oneDrive.activityEntity2a3649d6xxxxxx",
"#sharePoint.localizedRelativeTime": "0|July 30",
"action": {
"checkout": {}
},
"actor": {
"user": {
"email": "XXX#XXX",
"displayName": "vladimir",
"self": {},
"userPrincipalName": "XXX#XXX
}
},
"id": "XXXXXXXXXXXXXX",
"times": {
"recordedTime": "2018-07-31T04:59:03Z"
}
},
although no user ID at least a have the email....
I have setup a content type with a subject field that has pre assigned values in a dropdown field.
I am using the services api to post new content from a polymer app.
When I POST to the api I send the field structure and value in json but get and error.
"406 (Not Acceptable : An illegal choice has been detected. Please contact the site administrator.)"
Even though the object I am sending matches one of the required values in the field.
Do I need to prefix the value with something? I assume I'm posting to the right place to get that response but don't know why it would accept anything other than the string value.
Here is what I sent to the api which is picked up by my Charles proxy.
{
"node": {
"type": "case",
"title": "my case",
"language": "und",
"field_subject": {
"und": {
"0": {
"value": "subject1"
}
}
},
"body": {
"und": {
"0": {
"value": "my details of subject"
}
}
}
}
}
And here is an example of what I have setup in my Drupal field
subject1| first
subject2| second
subject3| third
subject4| forth
For anyone else with the same problem, this subject is poorly documented, but the answer is simple, my subject did not need the value key despite devel suggesting thats how it would be formatted.
"field_subject": {
"und": [
"subject1"
]
}
I could also shorten my code with "und" being an array.
I am designing a RESTful API for a mobile application I am working on. My problem is with large collections containing many items. I understand that a good practice is to paginate large number of results in a collection.
I have read the Facebook Graph API doc (https://developers.facebook.com/docs/graph-api/using-graph-api/v2.2), Twitter cursors doc (https://dev.twitter.com/overview/api/cursoring), GitHub API doc (https://developer.github.com/v3/) and this post (API pagination best practices).
Consider an example collection /resources in my API that contains 100 items named resource1 to resource100 and sorted descending. This is the response you will get upon a GET request (GET http://api.path.com/resources?limit=5):
{
"_links": {
"self": { "href": "/resources?limit=5&page=1" },
"last": { "href": "/resources?limit=5&page=7" },
"next": { "href": "/resources?limit=5&page=2" }
},
"_embedded": {
"records": [
{ resource 100 },
{ resource 99 },
{ resource 98 },
{ resource 97 },
{ resource 96 }
]
}
}
Now my problem is a scenario like this:
1- I GET /resources with above contents.
2- After that, something is added to the resources collection (say another device adds a new resource for this account). So now I have 101 resources.
3- I GET /resources?limit=5&page=2 as the initial response suggests will contain the next page of my results. The response would be like this:
{
"_links": {
"self": { "href": "/history?page=2&limit=5" },
"last": { "href": "/history?page=7&limit=5" },
"next": { "href": "/history?page=3&limit=5" }
},
"_embedded": {
"records": [
{ resource 96 },
{ resource 95 },
{ resource 94 },
{ resource 93 },
{ resource 92 }
]
}
}
As you can see resource 96 is repeated in both pages (Or similar problem may happen if a resource gets deleted in step 2, in that case one resource will be lost).
Since I want to use this in a mobile app and in one list, I have to append the resources of each API call to the one before it so I can have a complete list. But this is troubling. Please let me know if you have a suggestion. Thank you in advance.
P.S: I have considered timestamp like query strings instead of cursor based pagination, but that will make problems somewhere else for me. (let me know if you need more info about that.)
We just implemented something similar to this for a mobile app via a REST API. The mobile app passed an additional query parameter which represents a timestamp at which elements in the page should be "frozen".
So your first request would look something like GET /resources?limit=5&page=1&from=2015-01-25T05:10:31.000Z and then the second page request (some time later) would increment the page count but keep the same timestamp: GET /resources?limit=5&page=2&from=2015-01-25T05:10:31.000Z
This also gives the mobile app control if it wants to differentiate a "soft" page (preserving the timestamp of the request of page 1) from a "hard refresh" page (resetting the timestamp to the current time).
Why not just maintain a set of seen resources?
Then when you process each response you can check whether the resource is already being presented.