profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/andimarek/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

andimarek/generic-relay 29

Experimental Relay version which doesn't depend on React

andimarek/graphql-analyzer 13

Static analysis of GraphQL queries

andimarek/angular-testing 1

presentation about testing with angularjs

andimarek/discreet 1

get discreet dependencies for your project

andimarek/acop 0

Akka and forkjoin example code

PullRequestReviewEvent

pull request commentgraphql/graphql-spec

RFC: __fulfilled meta field

Thanks for the explanation @benjie

mjmahone

comment created time in 9 days

pull request commentgraphql/graphql-spec

RFC: __fulfilled meta field

My concern regarding this PR is that it seems to elevate fragments into something that execution engines need to preserve.

@andimarek I don't think this is correct; even after deep merging of the fragments either the field exists in the selection set or it doesn't - it doesn't actually matter that it was inside a particular fragment since it's just a field that always returns true. This is one of the beauties of Matt's proposal - it works with the existing field merging mechanics and is a very very small change to GraphQL implementations. Technically you could implement it with aliases of __typename and it would work in all spec-compliant GraphQL services today.

I understood it as the label Argument allows you to uniquely identify the selection set, which would mean you need preserve the selection set. But maybe this is not correct.

mjmahone

comment created time in 9 days

PullRequestReviewEvent

Pull request review commentgraphql/graphql-spec

Relax SameResponseShape algorithm to be compatible with covariant fields

 SameResponseShape(fieldA, fieldB):    * Let {typeA} be the return type of {fieldA}.   * Let {typeB} be the return type of {fieldB}.-  * If {typeA} or {typeB} is Non-Null.-    * If {typeA} or {typeB} is nullable, return false.-    * Let {typeA} be the nullable type of {typeA}-    * Let {typeB} be the nullable type of {typeB}+  * If {typeA} is Non-Null.+    * Let {typeA} be the unwrapped nullable type of {typeA}+  * If {typeB} is Non-Null.+    * Let {typeB} be the unwrapped nullable type of {typeB}

I think that is correct: we would have to consider the same logic as linked above.

IvanGoncharov

comment created time in 12 days

PullRequestReviewEvent

pull request commentgraphql/graphql-spec

Relax SameResponseShape algorithm to be compatible with covariant fields

I want to document for completeness sense that not all covariant fields are restricted in this way. You can actually query two different covariant fields IF the covariant type is not a Scalar/Enum. For example:

 type Query {
    pets: [Pet]
  }
  interface Pet {
    name: String
    owner: PetOwner
  }
  type Dog implements Pet {
    name: String
    owner: DogOwner
  }
  type Cat implements Pet {
    name: String
    owner: CatOwner
  }
  interface PetOwner {
    name: String
  }
  type DogOwner implements PetOwner {
    name: String
  }
  type CatOwner implements PetOwner {
    name: String
  }

Here owner is covariant for Cat and Dog. This query is valid:

{
  pets {
    ... on Dog {
      name
      owner {
        name
      }
    }
    ... on Cat {
      name
      owner {
        name
      }
    }
  }
}

Just to be clear: the reason is actually not that covariant is specifically handled, but the specific composed type returned doesn't matter when fields overlap.

IvanGoncharov

comment created time in 12 days

pull request commentgraphql/graphql-spec

RFC: __fulfilled meta field

Some early feedback here @mjmahone, could be very well I am missing something. Please correct me where I got something wrong.

My concern regarding this PR is that it seems to elevate fragments into something that execution engines need to preserve.

This would be a big change to GraphQL with huge (potential breaking) impact. As a real life example: in Atlassian in our GraphQL Gateway we are resolving all fragments before starting to execute the query and then the query is actually forwarded to other services for the actual execution. The forwarded query doesn't resemble the original query at all and all original fragments are gone.

The logic behind this "resolving all fragments" is based on the merged field validation: it basically merges all fields together and resolves all type conditions into Objects so that you only have a tree of fields. Here are a bunch of tests which make this hopefully clearer.

My gut feeling is that any improvements should come from __typename. That is basically all what counts at execution time (at least currently).

In general I am also not sure relying on the specific selections sets/fragments is great. Looking at your example above regarding the org

fragment A on Viewer {
  actor {
    __typename
    name
    ...B @include(if: $use_b)
    ... on Business @include(if: $use_business) {
      org
    }
  }
}

fragment B on User {
  org
}

You ask where org comes from: is it a Business Org or a User org. I am wondering: if this information is important for the client, why not explicitly ask for it in the query, for example by aliasing it?

fragment A on Viewer {
  actor {
    __typename
    name
    ...B @include(if: $use_b)
    ... on Business @include(if: $use_business) {
      businessOrg: org
    }
  }
}

fragment B on User {
  userOrg: org
}
mjmahone

comment created time in 13 days

issue commentgraphql-java/graphql-java

Ensure instrumentation field errors are populated in FetchedResult

yes that went out in 17.2

schenkman

comment created time in 15 days

issue closedgraphql-java/graphql-java

Ensure instrumentation field errors are populated in FetchedResult

Hi team! I am part of the Core API team at Twitter and we are currently in a large project migrating from Sangria to graphql-java to power Twitter's graphql infrastructure. We've been meaning to introduce ourselves and figured a PR would be the best way to do so.

Currently if a DataFetcher raises an exception in any way, the FetchedValue given in the instrumentation does not contain any errors information. The only place errors are available are on the ExecutionContext within a list, which is not ideal to determine if the current field has an error as we would need to iterate the list every time and that wouldn't be performant.

The attached PR has more information.

closed time in 15 days

schenkman
PullRequestReviewEvent

created taggraphql-java/graphql-java

tagv17.2

GraphQL Java implementation

created time in 21 days

release graphql-java/graphql-java

v17.2

released time in 21 days

push eventgraphql-java/graphql-java

Brad Baker

commit sha bb1ca20aafe800ed2ad4f5432dc2375195c1430e

Fixes glob matching on Windows

view details

Andreas Marek

commit sha 27b11d99d4885e81b0047a58ea88dd99b5a5b40f

Merge pull request #2513 from graphql-java/fix_glob_matching_on_window Fixes glob matching on Windows

view details

push time in 21 days

issue closedgraphql-java/graphql-java

DataFetchingFieldSelectionSetImpl getFields with child path

Describe the bug Failed to retrieve children path when use on Windows.

To Reproduce Please provide a code example or even better a test to reproduce the bug. Only on windows.

In a schema with returns a connection and should have edge { node { photo } }

For object DataFetchingEnvironment env

List<SelectedField> fields = toto.getFields("edges", "node/photo", "node\photo"); It does not return any fields

Problem comes from the resolve pattern

    @Override
    public List<SelectedField> getFields(String fieldGlobPattern, String... fieldGlobPatterns) {
        if (fieldGlobPattern == null || fieldGlobPattern.isEmpty()) {
            return emptyList();
        }
        computeValuesLazily();

        List<String> targetNames = new ArrayList<>();
        for (String flattenedField : flattenedFieldsForGlobSearching) {
            for (String globPattern : mkIterable(fieldGlobPattern, fieldGlobPatterns)) {
                PathMatcher globMatcher = globMatcher(globPattern);
                Path path = Paths.get(flattenedField);
                if (globMatcher.matches(path)) {
                    targetNames.add(flattenedField);
                }
            }
        }

        return toSetSemanticsList(targetNames.stream()
                .flatMap(name -> normalisedSelectionSetFields.getOrDefault(name, emptyList()).stream()));
    }

Because this is on windows, the value for Path path = Paths.get(flattenedField); will be edge\node\photo But the mkIterable(fieldGlobPattern, fieldGlobPatterns) produce :

  • edge
  • edge\node\photo
  • edge\node\photo

So no matching.

closed time in 21 days

ejouvin

PR merged graphql-java/graphql-java

Fixes glob matching on Windows

Fixes https://github.com/graphql-java/graphql-java/issues/2505

+11 -0

1 comment

1 changed file

bbakerman

pr closed time in 21 days

push eventgraphql-java/graphql-java

Chris Schenk

commit sha 482145f2fffcdc16012b5f693a776103f32e6c35

Ensure field errors are populated in FetchedResult before instrumentation `beginFieldComplete` is called Currently if a DataFetcher raises an exception in any way, the FetchedValue given in the instrumentation does not contain any errors information. The only place errors are available are on the ExecutionContext within a list, which is not ideal to determine if the current field has an error. This change ensures that FetchedValue contains errors if any was raised during `DataFetcher.get`.

view details

Chris Schenk

commit sha 3567bd7b169b6e3de2fecd149f5bebf0ebff986d

Remove unused import

view details

Chris Schenk

commit sha 908d9f0cd3f6a206256f4576e6cebd4f1aae8252

Update test name with issue number

view details

Andreas Marek

commit sha 8ca743dc72f54e7e99aeff1ce6ca3fb8a380b4b7

inline variable

view details

Andreas Marek

commit sha 45b590159e831a612a5193bce0552e3190a93d85

Merge pull request #2520 from schenkman/instrumentation_field_errors Ensure field errors are populated in FetchedResult

view details

push time in 21 days

PR merged graphql-java/graphql-java

Ensure field errors are populated in FetchedResult

Currently if a DataFetcher raises an exception in any way, the FetchedValue given in the instrumentation beginFieldComplete method does not contain any errors information. The only place errors are available are on the ExecutionContext within a list, which is not ideal to determine if the current field has an error. This change ensures that FetchedValue contains errors if any was raised during DataFetcher.get.

The solution simply allows the unboxPossibleDataFetcherResult to hit the result instanceof DataFetcherResult case which properly passes through errors in the ExecutionContext and in the FetchedResult itself. Since I'm not super familiar with the code base, this implementation has to cast to type T, which seems safe since the method was returning null in the first place but would defer to your suggestions to change.

Another possible solution is to expose a containsErrorPath method on ExecutionContext as the context maintains a Set<ResultPath> errorPaths which could be used to look up the current ResultPath in the instrumentation to see if it's an error. However, having the error directly on the FetchedValue seems to make more sense.

+47 -9

2 comments

2 changed files

schenkman

pr closed time in 21 days

PullRequestReviewEvent

push eventschenkman/graphql-java

Andreas Marek

commit sha 8ca743dc72f54e7e99aeff1ce6ca3fb8a380b4b7

inline variable

view details

push time in 21 days

PullRequestReviewEvent

push eventgraphql-java/graphql-java

Andreas Marek

commit sha 4d1e7acccef8b732595864f262099305a9c58e62

improving normalized field factory to handle diverged fields (wip)

view details

Andreas Marek

commit sha 69cb8444e21f8947c08dfcdfae93272899a8eeb7

improving normalized field factory to handle diverged fields

view details

Andreas Marek

commit sha bcbf499fe7f37cd45e418d1f6056defcaf5968b9

improving normalized field factory to handle diverged fields

view details

Andreas Marek

commit sha 577248b24e96d132b7fcacbb5a607492409dd562

more tests

view details

Andreas Marek

commit sha 351a75bedf34f9ffc125f917f9708b16c968b2bd

revised grouping algo

view details

Andreas Marek

commit sha 858779fff193a66eb3a92289f31bbf20c1d46dfc

all tests green

view details

Andreas Marek

commit sha 7b8fe35cec581561d2931ab0e05a28465304f1b3

cleanup

view details

Andreas Marek

commit sha f0c52ac62a6c4cca61b9b40c99e77596f0589e4c

more tests

view details

Andreas Marek

commit sha fac552dac03217935451a7f6fb40ca2b3fc5e161

fields which are not part of the same hierarchy should not be merged

view details

Andreas Marek

commit sha 9832a845daf6c5eded91adaa44e1d2770fce5c94

refining merging logic

view details

Andreas Marek

commit sha 5f98d6dd88d3f7399fe76d3e02461d70531301ff

Merge branch 'master' into nf-diverged-fields # Conflicts: # src/main/java/graphql/normalized/ExecutableNormalizedOperationFactory.java # src/test/groovy/graphql/normalized/ExecutableNormalizedOperationFactoryTest.groovy

view details

Andreas Marek

commit sha 45dc98a62c11760c3769fd9cd81be8249be50fca

Merge pull request #2511 from graphql-java/nf-diverged-fields Bugfix for ExecutableNormalizedOperationFactory

view details

push time in a month

PR merged graphql-java/graphql-java

Bugfix for ExecutableNormalizedOperationFactory

This PR fixes a problem with the ENOF which could lead to wrong executable normalized operations.

Specifically it is about diverging fields, which are fields with the same result key, but they can't be merged together:

E.g.:

       {
          pets {
            ... on Dog {
               friends { #P1
                 ... on Dog {
                    breed: dogBreed #F1
                 }
               }
            }
            ... on Cat {
             friends {  #P2
                ... on Dog {
                  breed #F2
                }
               }
            }
          }
        }

Here P1 and P2 need to result into two different normalized fields, because the children actually differ: F1 is different from F2.

+1208 -213

0 comment

10 changed files

andimarek

pr closed time in a month

push eventgraphql-java/graphql-java

Dariusz Kuc

commit sha 68c01ece238464591c9b0d3d2191ed30d0de62c6

update @deprecated definition description (#2510) Updating `@deprecated` definition description to match directive description.

view details

Davide Angelocola

commit sha bce9f2e8d1505538ccecc1fb71bb5196559abbae

update CONTRIBUTING.md (#2512)

view details

Franklin Wang

commit sha a6c01f27c13ed18dc20ded66f6c6b9703087dd56

Add operation name to ExecutableNormalizedOperation

view details

Franklin Wang

commit sha c123deee95b2d9524a5af5529589a3e4fb384f59

Fix test

view details

Franklin Wang

commit sha dd97159d1abe87020fc512fd022874114f7f9566

Add operation to ENO

view details

Andreas Marek

commit sha 493573bdb89d9faede16ea02846d8bc1b1a48b3a

Merge pull request #2514 from gnawf/expose-operation-name Add operation name to ExecutableNormalizedOperation

view details

Andreas Marek

commit sha 5f98d6dd88d3f7399fe76d3e02461d70531301ff

Merge branch 'master' into nf-diverged-fields # Conflicts: # src/main/java/graphql/normalized/ExecutableNormalizedOperationFactory.java # src/test/groovy/graphql/normalized/ExecutableNormalizedOperationFactoryTest.groovy

view details

push time in a month

push eventgraphql-java/graphql-java

Franklin Wang

commit sha a6c01f27c13ed18dc20ded66f6c6b9703087dd56

Add operation name to ExecutableNormalizedOperation

view details

Franklin Wang

commit sha c123deee95b2d9524a5af5529589a3e4fb384f59

Fix test

view details

Franklin Wang

commit sha dd97159d1abe87020fc512fd022874114f7f9566

Add operation to ENO

view details

Andreas Marek

commit sha 493573bdb89d9faede16ea02846d8bc1b1a48b3a

Merge pull request #2514 from gnawf/expose-operation-name Add operation name to ExecutableNormalizedOperation

view details

push time in a month

PR merged graphql-java/graphql-java

Add operation name to ExecutableNormalizedOperation

And also to the printer

+118 -19

0 comment

5 changed files

gnawf

pr closed time in a month

PullRequestReviewEvent

Pull request review commentgraphql-java/graphql-java

Add operation name to ExecutableNormalizedOperation

  @Internal public class ExecutableNormalizedOperation {-+    private final String operationName;

yes, exactly

gnawf

comment created time in a month

PullRequestReviewEvent

push eventgraphql-java/graphql-java

Andreas Marek

commit sha 9832a845daf6c5eded91adaa44e1d2770fce5c94

refining merging logic

view details

push time in a month