Conflicts between Organization and User


#1

When doing the following query

query Repos($count: Int!, $user: String!,
$after: String, $order: RepositoryOrderField = STARGAZERS,
$privacy: RepositoryPrivacy = PUBLIC) {
  rateLimit {
    resetAt
    remaining
    limit
    cost
  }

  user(login: $user) {
  repositories(privacy: $privacy, first: $count, isFork: false,
  affiliations: [OWNER, COLLABORATOR, ORGANIZATION_MEMBER], orderBy: {
  field: $order, direction: DESC }, after: $after) {
      totalCount
      pageInfo {
        startCursor
        hasPreviousPage
        hasNextPage
        endCursor
      }

      edges {
        node {
          id
          pushedAt
          nameWithOwner
          name
          url

          owner {
            ... on User {
              url
              name
              avatarUrl
              login
              id
            }

            ... on Organization {
              url
              org: name
              avatarUrl
              login
              id
            }
          }

          primaryLanguage { name }
          pullRequests(states: OPEN) { totalCount}
          issues(states: OPEN) { totalCount }
          stargazers { totalCount }
          forks { totalCount }
        }
      }
    }
  }
}

You have to alias name on the Organization because name on User is String! whereas name on Organization is String. While I like this distinction because it makes our code more simple than it would be otherwise, the inconsistency makes for a hard time.

Is this meant to be?


#2

:wave: @envygeeks,

Just to ensure that I fully understand what you mean, is the problem that in your code you are taking both User types and Organization types and trying to coerce them into a similar type, and it causes problems because one has a nullable name and the other doesn’t?

One of the benefits of union types is that it gives us the flexibility to have different return types so that they can be handled differently from type to type.

But all of this being said, I did a little digging, and it looks like we have a number of null values that could come back for name in both the case of Users and Organizations. I think the right move here is to make it nullable in both cases.


#3

Hi @envygeeks,

I’ve updated Organization.name to be nullable since we couldn’t guarantee its non-nullability. I hope this helps.

Brooks


#4

That’s perfect, thanks!