Our exact same endpoint demo query request using Freemium plan is different than the HERE API demo api endpoint results. As you can see, we do not have Address or contacts. I'm not sure why the results vary on same exact query and endpoint. Any ideas?
We have expanded the initial search/explore response based for the Demo App ID in order to enable users do some testing, but it is not turned on for the Freemium App ID. If you need specific details (like address and contact) then you can use places/lookup api like shown below (you search with source: sharing, id: id for the place you can get this from your above query).
We do this because we expect the end-user to select an item to get additional information. When selected, we receive that request, and it is a signal to us that the result is relevant and important to the query.
https://places.demo.api.here.com/places/v1/places/124aabd1-0aef738f80350f8bebb5ed7539bd19a8;context=Zmxvdy1pZD1lNjIyNjczZS0xNDRmLTViMzctYjY3Mi1hNWQ5MmRkNWU4NzRfMTU0MTc4NDk3MzYzOV8wXzU1NDcmc2l6ZT01JlgtRldELUFQUC1JRD1LTnZIaDlhZ0E2WGxKbElDRWhOZiZYLU5MUC1UZXN0aW5nPTE?app_id=xxx&app_code=xxx
Related
I tried to search for an example but, I presume it's not doable. I am looking to hopefully be proven wrong or to find an official confirmation that it's not doable.
Before using Hasura, I was doing transactional SQL queries that ensured that data was kept consistent.
For example, I would like to create a password reset token if a user requests it, only if the user can be found using an email address. Right now, I have to do 2 queries:
Try to find a user with the specified email address
Insert and assign the token to this user id
In that case, it's not too bad, but now if I want to consume that token, I have to do 3 queries:
Find the valid token
Change the password to the user associated with that token
Delete the token
Obviously, if something goes wrong and the token is not deleted, this could be an issue - so I would be curious to see if there would be ways to merge these queries/mutations into transactions.
Sounds like supporting nested updates would solve this problem for you with the least amount of effort. We are working on a rfc for the feature and hope to start development soon. Please follow this Github issue on our community for future updates.
https://github.com/hasura/graphql-engine/issues/1573
This comment outlines the current scope of the proposed feature. The rfc will provide a more complete explanation.
https://github.com/hasura/graphql-engine/issues/1573#issuecomment-1338057350
You can apply changes to rows that you filter by certain criteria. Here is a sample mutation:
mutation PasswordUpdate($id: uuid!, $token: String!, $new_password: String!) {
update_user(
where: {id: {_eq: $id}, token: {_eq: $token}}
_set: {token: null, password: $new_password}
) {
affected_rows
}
}
That query deletes the token and sets a password for all users (hopefully just one) that have the token assigned.
After some research here is what I found:
For the first example:
Try to find a user with the specified email address
Insert and assign the token to this user id
There are no solutions for this today and as answered by #damel, there is an ongoing RFC to support nested mutations: https://github.com/hasura/graphql-engine/issues/1573#issuecomment-1338057350
Hopefully, this feature will be out soon, but in the meantime, for most cases, it's not such a big deal to have multiple queries as it is possible to catch errors on the first query.
For the second example:
Find the valid token
Change the password to the user associated with that token
Delete the token
When sending multiple mutations in the same query, Hasura treats them as a transaction as announced in 2020.
Of course, it would be nice to do this in the same query (similar to the first example) but since there is a transaction on the mutation, for this case it's still not a problem.
I am sure there are probably cases where this can become a problem but I am not exposed to them right now. Nevertheless, it would be great if the RFC makes it to production, giving more options to Hasura users.
Google deprecated the old GMB API v4.9 account.locations.get endpoint, and replaced it with Business Information API v1 locations.get.
Code change that affects me is:
Removal of LocationState object. The existing fields have been moved into Metadata.
The new Metadata object does not return the attributes LocationState object contained before. The ones I'm interested in are:
isVerified
isPublished
isSuspended
isDisabled
isDisconnected
etc...
My question is:
How could I get this data without using deprecated endpoints?
Try Verification API getVoiceOfMerchantState
isVerified (verify),
isPublished (hasVoiceOfMerchant=true AND hasBusinessAuthority=true),
isSuspended (complyWithGuidelines),
isDuplicate (resolveOwnershipConflict).
isDisabled & isDisconnected have no equivalent in new API
As far as I can see, based on the link you have sent it is written:
Endpoint URL:
Endpoints for all business information, attributes, categories, chains and locations search are accessible at https://mybusinessbusinessinformation.googleapis.com/v1/ instead of https://mybusiness.googleapis.com/v4/
The path name for locations endpoints has changed from
accounts/accountId/locations/locationId to locations/locationId
Maybe it was better if you could provide the request uri in the previous version so we could help you more precisely. Anyhow, what I tested in the google playground is as follows:
open [https://developers.google.com/oauthplayground]
after setting your clientId and Authorisation stuff, in the Request URI write
https://mybusinessbusinessinformation.googleapis.com/v1/locations/XXXXX?readMask=storeCode,metadata,profile,serviceArea,labels,adWordsLocationExtensions
instead of XXXXX, write your locationId
you can write different readMask fields, The possible fields for readMask are:
play with different fields to check if you have your desired one or not readMask="storeCode,regularHours,name,languageCode,title,phoneNumbers,categories,storefrontAddress,websiteUri,regularHours,specialHours,serviceArea,labels,adWordsLocationExtensions,latlng,openInfo,metadata,profile,relationshipData,moreHours";
If above does not help you, in the link below I see that all metadata attribute of a location might be:
Click [here] (https://developers.google.com/my-business/reference/businessinformation/rest/v1/accounts.locations#Location.Metadata)
Using this, it is possible to take the badges from a specific user of Stack Overflow:
library(stackr)
badges <- stack_users(9371451, "badges", num_pages=100000, pagesize=100)
How can I add a parameter to take also the timestamp that the badge was awarded to the user? And if possible, for which answer?
you can use users/{ids}/timeline. See description page:
Returns a subset of the actions the users in {ids} have taken on the site.
This method returns users' posts, edits, and earned badges in the order they were accomplished.
library(stackr)
df_timeline <- stackr:::stack_GET("users/9371451/timeline", num_pages = 10000)
The ::: is necessary because the function stack_GET is an internal command
It is possible-ish with the Stack Exchange API, but not with the stackr library you are using.
The /users/{ids}/badges route returns a list of badge objects, which only has these possible properties:
award_count integer
badge_id integer, refers to a badge
badge_type one of named, or tag_based
description string
link string
name string
rank one of gold, silver, or bronze
user shallow_user
So you can't get the timestamp or triggering post there.
However, you can get this information (mostly) from the /notifications route, which can return results like:
{ "items": [ {
"site": {"site_url": "https://webmasters.stackexchange.com"},
"is_unread": false,
"creation_date": 1520234766,
"notification_type": "badge_earned",
"body": `You've earned the \"Notable Question\" badge for
<a href=\"http://webmasters.stackexchange.com/questions/65822\">
How to bulk delete email accounts from cPanel / my hosting account?</a>.`
// Manually wrapped for this post
},
etc.
But, important:
/notifications requires authentication and only works for a logged-in (via the API) user.
That stackr library does not support authentication. (See your previous question in a bit.)
/notifications returns all of a given user's Stack Exchange sites, so you will have to filter out the ones you are not interested in.
/notifications returns several kinds of notices, so you will have to filter out the ones that are not badge related.
/notifications does not return badge details like rank, so you will still need to call /users/{ids}/badges and marry the results.
For higher rep users, it is possible that you would exhaust your API quota before being able to fetch all of that user's notifications.
In running the graph API that is given as sample: https://graph.microsoft.com/v1.0/me/, it returns an output in the screen
What info is it returning and how can I use it in a user interface....
The easiest way to see what info is returned and try out different calls is to use the Graph Explorer at https://graph.microsoft.io/en-us/graph-explorer.
Otherwise, check the documentation at https://graph.microsoft.io/en-us/docs.
That API endpoint (https://graph.microsoft.com/v1.0/me/) return the user profile.
Here is the detail: https://graph.microsoft.io/en-us/docs/api-reference/v1.0/api/user_get
You can use the information however you wish on your client (e.g., display list of current licenses, display user information for confirmation and updates, etc.). Other user-related methods are here: https://graph.microsoft.io/en-us/docs/api-reference/v1.0/resources/user
Whenever I encounter code snippets on the web, I see something like
Meteor.subscribe('posts', 'bob-smith');
The client can then display all posts of "bob-smith".
The subscription returns several documents.
What I need, in contrast, is a single-document subscription in order to show an article's body field. I would like to filter by (article) id:
Meteor.subscribe('articles', articleId);
But I got suspicious when I searched the web for similar examples: I cannot find even one single-document subscription example.
What is the reason for that? Why does nobody use single-document subscriptions?
Oh but people do!
This is not against any best practice that I know of.
For example, here is a code sample from the github repository of Telescope where you can see a publication for retrieving a single user based on his or her id.
Here is another one for retrieving a single post, and here is the subscription for it.
It is actually sane to subscribe only to the data that you need at a given moment in your app. If you are writing a single post page, you should make a single post publication/subscription for it, such as:
Meteor.publish('singleArticle', function (articleId) {
return Articles.find({_id: articleId});
});
// Then, from an iron-router route for example:
Meteor.subscribe('singleArticle', this.params.articleId);
A common pattern that uses a single document subscription is a parameterized route, ex: /posts/:_id - you'll see these in many iron:router answers here.