I'm trying to group graphQL queries to have a more organized response.
I want to make a query for allEmployees and get back something in the following format
GraphQL Query
{
Employees:allEmployees{
id
firstName
lastName
}
}
Response
{
"data": {
"Employees": [
"new":[
{
"id": "1",
"firstName": "James",
"lastName": "Test"
},
{
"id": "3",
"firstName": "Charles",
"lastName": "Tes"
}
],
"updated":[
{
"id": "4",
"lastName": "Test"
},
],
"deleted":[
{
"id": "1",
},
],
}
}
}
I've looked into a few options to get named sub-request( like new, updated and deleted) via aliases on fragments but that doesn't seem to be a thing. I've looked at unions, but that doesn't seem to be what I'm looking for.
Ideally I would love to query graphql like...
{
Employees:{
new: allEmployees(status:"new"){
id
firstName
lastName
}
updated: allEmployees(status:"updated"){
id
firstName
lastName
}
deleted: allEmployees(status:"deleted"){
id
}
}
but I don't think it is possible to pass a nested query like this.
Is there anyway to do something like this? I'm using graphql with ruby via the graphql-ruby gem.
please let me know if anyone needs more information?
Thanks
Edit
To clarify. We have multiple entities that will follow the new, updated, deleted pattern. Looking to try and get a response where the results are nested inside a parent name/alias (Employees, Users)
{
"data": {
"Employees": [
"new":[...],
"updated":[...],
"deleted":[...],
],
"Users": [
"new":[...],
"updated":[...],
"deleted":[...],
],
...
}
That is why we would want to nest
GraphQL definitely supports nested queries and multiple top-level queries, and graphql-ruby supports these just fine.
If your GraphQL schema looks like:
type Employee {
id: ID!
firstName: String
lastName: String
}
enum Status { NEW, UPDATED, DELETED }
type Query {
allEmployees(status: Status): [Employee!]!
}
then you could write a query
fragment EmployeeData on Employee { id firstName lastName }
query Everyone {
new: allEmployees(status: NEW) { ... EmployeeData }
updated: allEmployees(status: UPDATED) { ... EmployeeData }
deleted: allEmployees(status: DELETED) { ... EmployeeData }
}
That wouldn't have quite the specific form you're looking for – there aren't good ways to add or remove arbitrary levels in your query, like adding an "Employees" label or removing layers from React-style connection records – but it can retrieve the data you're looking for.
Related
GraphQL lets you ask for specific fields, the response contains only the fields that you had asked for. For example:
a graphql query like:
{
hero {
name
}
}
will return:
{
"data": {
"hero": {
"name": "R2-D2"
}
}
}
where as a graphQl query like:
{
hero {
name
friends {
name
}
}
}
would return:
{
"data": {
"hero": {
"name": "R2-D2",
"friends": [
{
"name": "Luke"
},
{
"name": "Han Solo"
},
{
"name": "Leia"
}
]
}
}
}
Is there a similar mechanism/library/pattern that can be used in gRPC to achieve the same?
FieldMask is similar in protobuf. It is a list of fields to retain, so the first example would be paths: "hero.name" and the second would be paths: ["hero.name", "hero.friends.name"].
It is probably most frequently used to specify which fields should be changed in an update. But it can equally be used to specify the fields that should be returned.
The server can either process the FieldMask directly (e.g., only using the listed fields in a SELECT SQL query), or it can retrieve all the information and filter the result using FieldMaskUtil.merge() to copy just the requested fields into a new proto message to return to the client.
I have a document structured as follows, more or less:
post {
_id
title
isPublished
}
user {
_id
username
name
[posts]
}
I know I can query fields like postConnection and userConnection with the aggregate subfield in order to query a count of all objects. But how do I get the total count of all posts by a given user?
I was able to come up with this:
{
postsConnection(where: {isPublished: true}){
groupBy{
author{
key
connection{
aggregate{
count
}
}
}
}
}
}
But this returns (expectedly) something like this:
{
"data": {
"postsConnection": {
"groupBy": {
"author": [
{
"key": "5c9136976238de2cc029b5d3",
"connection": {
"aggregate": {
"count": 5
}
}
},
{
"key": "5c99d5d5fcf70010b75c07d5",
"connection": {
"aggregate": {
"count": 3
}
}
}
]
}
}
}
}
As you can see, it returns post counts for all authors in an array. What I need is to be able to return the count for only one specific user and not by _id (which is what the key field seems to map to) but by another unique field I have in the users collection, i.e. username.
Is that possible?
Need to pass in a parameter to either the query or the field to return specific data
Here is query where I try to use distinct in graphQl query:
query{
contacts(take: 10, distinct: true) {
firstName
lastName
title
}
}
But I am getting error:
{
"errors": [
{
"message": "Unknown argument \"distinct\" on field \"contacts\" of type \"QuerySchema\".",
"locations": [
{
"line": 2,
"column": 21
}
]
}
]
}
GraphQL has no built-in sorting/filtering. It is up to the server to implement features like that, so if you're relying on a third party API and it doesn't support it then you will have to filter the response yourself.
You need to specify the column that GraphQL will use to check wether a value is distinct. In your case you can do something like:
query MyQuery {
contacts(distinct_on: firstName) {
firstName
lastName
title
}
}
Here is a example of distinct query.
query {
contacts {
distinct(field: title)
}
}
Result will be.
{
"data": {
"contacts": {
"distinct": [
"This is my test post",
"This is my test post1",
"This is my test post2"
]
}
}
}
This query binds all titles and deduplicates.
I would like to specify inner constraints in a GraphQL query that would limit the results of the outermost query as part of a query / predicate builder I'm working on. I'm not sure if this is considered to be within GraphQL's capabilities but it makes sense to me as something that people would want to do.
For example, I might want to show a list of blog posts that were recently commented on like this:
{
posts{
title
date
comments(since: $earliestDate){
body
date
author {
name
}
}
}
}
The normal behaviour of this would be to bring back all blog posts and only comments that met the criteria.
{
"posts": [
{
"title": "Post 1",
"date": "2017-07-31"
"comments": [
]
},
{
"title": "Post 2",
"date": "2017-06-10",
"comments": [
{
"body": "Comment text",
"date": "2017-08-09",
"author": {
"name": "Michael"
}
}
]
}
]
}
But I want my query to prevent the retrieval of "Post 1" because it has no comments in the last month, but I'm not sure that's something GraphQL will make easy to do.
Is there functionality within GraphQL to support returning this result?
{
"posts": [
{
"title": "Post 2",
"date": "2017-06-10",
"comments": [
{
"body": "Comment text",
"date": "2017-08-09",
"author": {
"name": "Michael"
}
}
]
}
]
}
TL;DR - In general, you want the behavior of a field to only be defined by:
The arguments passed to that field
The identity of the object that is being queried
The global context of the query (eg, the identity of the user executing the query)
I think that the behavior you're after is not really ideal for GraphQL. At least as I've seen, GraphQL tends to treat fields as relatively independent from each other (even though they're nested).
For example, you would not expect arguments passed to a child field to change the behavior of its parent. And similarly, I think you would not expect the presence or absence of a child field to change the behavior of its parent.
The best way to accomplish the behavior you're after would be to add an argument to the posts field, indicating that only posts with comments should be returned:
{
posts(withCommentsOnly: true) {
title
date
comments(since: $earliestDate) {
body
date
author {
name
}
}
}
}
To understand the reasons why, just think about these kinds of scenarios:
{
authors {
id
posts {
comments { body }
}
}
}
If this query has the behavior you describe, for each author, you would only get the posts which also have comments. But then imagine that you re-query one of those authors later:
{
node(id: "author_id") {
... on Author {
posts { title }
}
}
}
Now would you get a different set of posts? That kind of behavior would make it very difficult for people to query your GraphQL schema using standard GraphQL clients, because client-side caching mechanisms would probably not be able to correctly update their caches.
I am new to elastic search spring data, Today I was trying to get In query working with Spring data ES repository.
I have to do a lookup for list of user names, and if its exactly match in the index, need to get those users back as result.
I tried to use the built in repository 'In' method to do so, but it returns partial matches, please help me to make this working like SQL IN query.
Here is my repository code:
public interface UserRepository extends ElasticsearchRepository<EsUser, String>
{
public List<EsUser> findByUserAccountUserNameIn(Collection<String> terms);
}
REQUEST:
{"terms":["vijay", "arun"], "type":"NAME"}
RESPONSE:
[
{
"userId": "236000",
"fbId": "",
"userAccount": {
"userName": "arun",
"urlFriendlyName": "arun",
},
"userProfile": {
},
"userStats": {
}
},
{
"userId": "6228",
"userAccount": {
"userName": "vijay",
"urlFriendlyName": "vijay",
},
"userProfile": {
},
"userStats": {
}
},
{
"userId": "236000",
"fbId": "",
"userAccount": {
"userName": "arun singh",
"urlFriendlyName": "arun-singh",
},
"userProfile": {
},
"userStats": {
}
}
{
"userId": "236000",
"fbId": "",
"userAccount": {
"userName": "vijay mohan",
"urlFriendlyName": "vijay-mohan",
},
"userProfile": {
},
"userStats": {
}
}
]
This is because your userAccount.userName field is an analyzed string, and thus, the two tokens arun and singh have been indexed. Your query then matches the first token, which is normal.
In order to prevent this and guarantee an exact match you need to declare your field as not_analyzed, like this:
#Field(index = FieldIndex.not_analyzed)
private String userName;
Then you'll need to delete your index and the associated template in /_template, restart your application so a new template and index are created with the proper field mapping.
Then your query will work.