Invoice Parser documentation lists the fields that this processor attempts to find in a document.
https://cloud.google.com/document-ai/docs/processors-list?hl=en_US#processor_invoice-processor
I am only interested in some of the fields in the Invoice processor, is there a way to get the list of fields and request the processor to find the data points for a selected set of fields?
E.g. I am only interested in invoice_date and invoice_id. So, the processor only finds these two fields for me and does not waste its time finding others.
I found an endpoint that retrieves the processor's details but it does not get the field list.
https://cloud.google.com/document-ai/docs/reference/rest/v1beta3/projects.locations.processors/get
This process endpoint does not have anything to specify the fields that I am interested in.
https://cloud.google.com/document-ai/docs/reference/rest/v1beta3/projects.locations.processors/process
My research indicates that this feature does not exist, hoping someone tells me that I am wrong.
Currently, it's not possible to limit the specific entities that are extracted by a specialized processor. The processor will always processes the entire document and extract everything it can find.
However, a new parameter has recently been added to the process method in the REST API that lets you provide a fieldMask to limit the fields that will be returned in the Document object. This has also been added to the How-to Guide for making a processing request. Currently, this only works for the REST API (not client libraries) and online processing.
This isn't exactly what you're looking for, but it can significantly limit the size of the Document response if you don't need fields like content
Related
I'm working with calendar information in the XML response from the MS server. I successfully extract fields from CalendarItem, but I also need some of the fields from CalendarItem's ancestor, Item. The response from the server contains that information in xml, so I believe I can use "from_xml" to get, for example, the "item:TextBody".
If "from_xml" is the right approach, how should I use it? If I'm on the wrong path, how should I proceed?
What exactly are you attempting to do? exchangelib makes all values in the XML available as attributes on the returned items. There are lots of examples in the documentation.
CalendarItem is a subclass of Item so the fields on the superclass are also available to the subclass. You can see all available fields by renting CalendarItem.FIELDS.
I'm trying to build a simple API which should do the following:
A user makes a request on /getContent endpoint, with the geographical coordinates for this user. By content, it means audio files.
Every time they send a request, we should just get a random object from a Model and return the URL field from it, to be consumed by the front end. For this, it can be a random one, it doesn't matter much which one.
Also, we should keep tracking about the requests each user makes. This way, we can check how many requests the user has made, and when they were made.
Every 5 requests or so, the idea is to send the user a customized content based on their location. My idea is to store this content in another model, since it would have many more fields in comparison from the standard content.
Basically, at every request, I'd check if it's time to send a special content. If not, just send the random one. Otherwise, I'd check if the time is appropriate, and the user is within a valid location based on the special content's data in the model. If this validation passes, we send the URL of the special content, otherwise, we just send the random one.
I'm having a hard time figuring out the best way to design this. My initial idea is to have two different models:
Model 1: Standard content. It has some fields to its meta data, such as duration, title and other stuff like this.
Model 2: Custom content. Besides the meta data, it should contain the geographical data, and the datetime range. This will allow the checking to be made if the content should be played or not.
Now it's the part I'm pretty much clueless. How to make it all work together?
QUESTIONS
Maybe storing every single request data from every user, and checking this data might not be very effective. It would require some writing at every request instead of just reading.
Since I'd be using two different models, how can I make the decision to happen in the view? I mean, the final output would be the same, an URL. But I'd have to make the decision process to happen in the view on which model to use.
I appreciate the help!
My question is about designing an endpoint for getting a list of items in a collection. Here my understanding is that a GET on a collection returns a list of the items in that collection, but no details about these.
A list of resource IDs isn't very nice for a human being, so a GUI front-end would then request details of each item in the collection.
If the collection is say the "users" then the GET on the collection just returns a list of user IDs (ALL OF THEM! Paged, I imagine?)
The GUI then requests details for every ID and uses this to populate an interface. For a list you might say, as an example, just show the user's Full name and Email address in this interface, allowing the user to select one to see more details.
Now I'm thinking it would save a lot of back and forward between the client and the API if the "list retrieve" returned a bit more than just the IDs, maybe include ID, full-name and Email address for each item.
Does that break RESTful-ness? Where do you stop with how much detail to return in a single request? Do you allow the client to specify which attributes to include as part of the request?
What about "searching" a collection? Do you allow arguments to be specified on the GET against the collection to "filter" the results?
The API exists to service the needs of the clients. If your clients need the details, you should be returning them.
That said, there's a tradeoff for highly-cacheable items. If the list is not static but the contents are, you might be better served returning the list of links. Then the client makes one call for each element, and they sit in the cache. Later calls for those elements get served by an intermediate cache, either on the client or somewhere between client and server. That would reduce overall bandwith of calls to the list at the cost of a larger absolute number of calls at first.
Another option is to support a query parameter like ?include=id, full-name, email. By default just return the self link, but clients may specify what properties they'd like to have populated in the representations they get back. If you support this query parameter, I would suggest defaulting to returning only the most essential information.
As far as searching the collection, it depends on the nature and complexity of the search. Query parameters are one option. Using POST to a search endpoint and sending up the search criteria in the body is also reasonable, especially if your url might be longer than 2k characters (the default url length limit for some browsers). You can also do saved searches this way - let the POST create a search criteria resource on the server, and let clients GET /widgets?search-criteria=<id>.
Summary
I have a bit of a problem using Ember-Model, trying to establish a unique relationship between two models.
Based on current responses that I have received here on S.O., Ember Forums, and #emberjs. I am beginning to believe that there is no built-in solution for this problem, and I am reformatting my question to specify what is needed.
Details
I am populating a template currently with a full set of debtor information. All the information comes from multiple calls to the server.
The first bit is the basic Debtor info. This part is easy because I can use the model hook and a dynamic segment to retrieve it.
My server returns a JSON for a Debtor... Here's the short version:
{
"debtor" = {
"debtor_id": 1003,
"debtor_name": Steve,
//... more JSON
"debtor_contact_id": 1345
}
}
The dynamic segment for Debtor is filled with the value of the debtor_id, but also notice this debtor has a debtor_contact_id. Every Debtor record retrieved from the server has a unique debtor_contact_id. On the database, this value is a "foreign key" that will tell which contact table belongs to which debtor table.
There is no way to predict which contact info relates to which debtor without this key/value pair.
I currently have "Contacts" belongsTo "Debtor", but that is not enough to do the job.
When it is time to fill the "Contacts" model. Ember-Model needs to know to build the value from debtor_contact_id into the ajax URL as a query parameter in order to GET the correct API.
I am still learning all of this stuff and so far I have not been able to fully follow any tutorials because my use case has an extra step needed somewhere.
This is the expected behavior I am hoping to see:
Model hook will work as expected to pull the specific debtor and put it into a "debtor" model (this part is currently working just fine)
Somehow "debtor_contact_id" is read from the payload
that value is added as part of a server query to find a separate API
the resulting contact info will be pulled into a "contact" model
hopefully a hasMany/belongsTo relationship can be established after both corresponding models are returned.
all this needs to be done in one promise before entering my template
You will also find the question at: discuss.emberjs.com if that is more appropriate place to discuss.
I can elaborate more if this does not make sense... thanks!
Assuming you are using ember-data, alongside the attributes of your model you need to add:
debtor_contact: DS.belongsTo('name_of_the_other_model')
This then provides you a promise which will resolve to the other model on demand. It won't resolve straight away, but bound variables in templates will update as it is resolved. The other API call will be made for you if things are set up properly.
http://emberjs.com/api/data/classes/DS.html#method_belongsTo
The answer I gave here might also be helpful if you need to force resolving the relationship for some reason: Ember Unbound & Belongsto
I'm doing a query of this form:
https://graph.facebook.com/search?q=Beshoff&fields=likes,checkins,products,name,talking_about_count,description,category&type=place¢er=37.327453,-121.813102&distance=400
I am interested in finding out the exhaustive list of fields that can be selected for a Place object.
In particular, on the facebook page for a specific place, there are often multiple categories listed which I have been unable to figure out if it's possible to retrieve using the Graph API.
e.g. On https://www.facebook.com/BeshoffInfiniti, there is an entry "Car Dealership" but the graph api call above returns "Local business".
If you leave out the "fields" attribute in your query you will get all the fields. The number of fields depends on the object type (for example owned pages vs. wiki pages)
Don't just look at the Graph API. Take a look at FQL. There are different fields available in FQL vs. the API. And yes, using the distance function you can look for places in an area.
Graph API != FQL
One thing to try is the Facebook Open Graph schema entry for Page and Place.
You'll find all the additional fields for Pages. You can think of places as a subclass of pages.
If you're curious about the types of page that might be returned, try having a look through the create a page flow.