Correct me if I'm wrong but it appears that the admin-sdks's Users>list operation doesnt support searching users by ID (According to the docs here).
For example I use the Members api to get all the members of a given group. It returns a list or User Ids.
The only way to fetch data about those users is to call the get operation for each user. Seems pretty inefficient to me.
How come this functionality is not implemented (or perhaps I'm missing something)?
Search feature means you have a pattern and you want the list of all entities which relate to given pattern. It assumes you don't have the unique id of the entity you need. The output of search feature is the list of unique ids with optional additional minimal information which matches to search pattern. To get full information of the individual entity, you need to use unique id and use get information feature.
However, if you already have the unique id, then you don't need the search function. Directly use get information feature.
So google has provided sufficient functionality. If you already have userid, why using search call, use retrieve user call directly.
Related
I want to work with Elasticsearch to process some Whatsapp chats. So I am initially planning the data load.
The problem is that the data exported from Whatsapp, doesn't contain a real unique id per user but it only contains the name of the user taken from the contact directory of the device where the chat is exported (ie. a user can change the number or have two numbers in the same group).
Because of that, I need to create a custom explicit mapping table between the user names and a self-generated unique id, that gets populated in an additional column.
Then, my question is: "How can I implement such kind of explicit mapping in Elasticsearch to generate an additional unique column?". Alternatively, a valid answer could be a totally different approach to the problem.
PS. As I write, I think the solution could be in the ingestion process, like in a python script, but I still want to post the question to understand if this is something that Elasticsearch can do by itself.
yes, do it during the index process
if you had the data that maps the name and the id stored in a separate index you could do this with an enrich processor when you index the data to add whichever value you want to the document via a pipeline
also - Elasticsearch doesn't have columns, only fields
In Laravel Lighthouse GraphQL, I'd love to be able to delete records that match certain conditions rather than passing just an individual ID.
I get this error:
The #delete directive requires the field deletePostTag to only contain a single argument.
This functionality seems currently unsupported, but if I'm wrong and this is actually supported, please let me know, because this would be the most straightforward approach.
So then my second approach was to try to first run an #find query to retrieve the ID of the record that I want to delete (based on certain fields equaling certain values).
But https://lighthouse-php.com/4.16/api-reference/directives.html#find shows:
type Query {
userById(id: ID! #eq): User #find
}
and does not show how I could provide (instead of the primary key ID) 2 arguments: a foreign key ID, and a string.
How can I most simply accomplish my goal of deleting records that match certain conditions (rather than deleting via primary key)?
I'm not sure about the #delete functionality regarding multiple arguments, but from what you've posted that appears to be unsupported at the moment. Regarding your query, you should instead use something like #all in conjunction with #where which would allow you to filter the collection by as many vars/args as you'd like. If your argument list grows beyond 3 or so, I would take a look at Complex Where Conditions. They have worked very well for my team so far, and allow a lot of filtering flexibility.
Also take a look at the directive's docs stating:
You can also delete multiple models at once. Define a field that takes a list of IDs and returns a collection of the deleted models.
So if you return multiple models you'd like to delete from your query, you may use this approach to delete them all at once.
I've just spent a long time reading documentation about the Google API Places, and there's some information I don't quite understand.
I need to build an application that can record a travel plan for a user, so a sequence of places.
For this, I need a very simple form, with a "destination" input, which will use "Autocomplete Places".
This endpoint return a place_id for the selected location, which is the only thing I'm allowed to store in a database, according to Google's terms and conditions.
So in my idea, I'll store this id, and a itinerary would be made of a sequence of place_id, without the need to store the place name or anything else. To display the user's itinerary, I'd just have to make Place Details queries, with the identifier.
But the documentation specifies that these ids can change over time, so they advise to redo queries "periodically" to refresh the place_id.
But how can I redo queries if I haven't stored any information about the place, other than the place_id ? Do I need to store the name of the place (and do I have the right to do that?) to be able to retrieve its ID, or am I missing something?
Another thing: I didn't find, or didn't understand, in the terms of use, if I was allowed to store data generated by my site beside Google IDs, for example, to store comments about places.
Sorry if I make language mistakes, im not fluent in english.
Thanks !
I am new to FHIR, and am unable to understand the concept of compartment search.I have read compartment is a group of similar resources, but when we do compartment search we provide the following path:
/[compartment]/[id]/?[parameters]
'/[compartment]/[id]/[type]?[parameters]'
'/[compartment]/id/condition '
Can anyone please give reasons why we are using ID as a parameter in each request, and also please give one one example of each request.
You can do this:
/Patient/1/$everything, however that's not really a compartment based search. It's a resource-instance specific operation that depends on the existence of compartments to function - it says "find me everything in this patient's compartment"
For compartment based search, you'll either have this:
/[compartment]/[id]/[type] (e.g. /Patient/1/Condition) if you want all records of the specified type within the compartment
or this
/[compartment]/[id]/[type]?[parameters] (e.g. /Patient/1/Condition?category=diagnosis) if you want to further filter the records.
id isn't a parameter, it's identify the compartment. In the example above, you're saying "I want the conditions that belong to patient 1". There's no difference between the following two queries:
/Patient/1/Condition
/Condition?patient=1
The only reason we support compartments is that some systems like to do logic or security based on URL. Nesting queries beneath a selected Patient or Practitioner, etc. lets them do that.
I'm trying to build a simple reviews site for a very specific search parameter, which I can pull information back from Google Places API. I understand I cannot store any information other than what Google says I can, and it sounds like I can only store the "reference" parameter and the "id" parameter.
Upon creation of a review for a place returned from Google, I need to store some identifier so that when someone else searches Google Places through my site, I can do an AJAX call to my DB and pull all reviews for that Place.
Ultimately, my question is, which key should I store? Or both?
As per the documentation:
id contains a unique stable identifier denoting this place. This
identifier may not be used to retrieve information about this place,
but is guaranteed to be valid across sessions. It can be used to
consolidate data about this Place, and to verify the identity of a
Place across separate searches.
reference contains a unique token that you can use to retrieve
additional information about this place in a Place Details request.
You can store this token and use it at any time in future to refresh
cached data about this Place, but the same token is not guaranteed to
be returned for any given Place across different searches.
It would make sense to store both, reference to retrieve reviews from Google Places and id to group your place reviews in your db.
As of June 24, 2014 the id and reference fields are deprecated. placeId (for requests) and place_id (in responses) should be used instead.
The Places API currently returns a place_id in all responses, and accepts a placeid in the Place Details and Place Delete requests. Soon after June 24, 2015, the API will stop returning the id and reference fields in responses. Some time later, the API will no longer accept the reference in requests. We recommend that you update your code to use the new place ID instead of id and reference as soon as possible.