Documentation

Represents the format of the metadata a remote relationship was read from and must be written back as. We don't have a good way of doing metadata versioning yet, and we therefore use this to keep track of the format used.

Specify whether remote schema <> source relationships should be built

Metadata representation of the internal definition of a remote relationship.

Whether to accept legacy fields when parsing RemoteRelationshipDefinition

Parse RemoteRelationshipDefinition letting the caller decide how lenient to be.

This is necessary because RemoteRelationshipDefinition is parsed in different contexts. In RemoteRelationship, the RemoteRelationshipDefinition is always parsed out from a top-level @"definition" field. Thus, a legacy payload looks like this:

{
  "name": "thing",
  "definition": {
    "remote_schema": "stuff",
    "hasura_fields": ...
    "remote_field": ...
  }
}

and a new payload looks like this:

{
  "name": "thing",
  "definition": {
    "to_remote_schema": {
      "schema": "stuff",
      "lhs_fields": ...
      "remote_field": ...
    }
  }
}

In contrast, CreateFromSourceRelationship does not have a top- level "definition" in its legacy format. Instead, the legacy fields themselves are top-level:

{
  "remote_schema": "stuff",
  "hasura_fields": ...
  "remote_field": ...
}

Furthermore, the presence of a "definition" field is used to detect that the new payload is being used:

{
  "definition": {
    "to_remote_schema": {
      "schema": "stuff",
      "lhs_fields": ...
      "remote_field": ...
    }
  }
}

In this latter case, we should not allow "remote_schema" to appear under "definition".

Resolved remote relationship, as stored in the schema cache.

Resolved remote relationship's RHS

Information about the field on the LHS of a join against a remote schema.

Information about a computed field appearing on the LHS of a remote join. FIXME: why do we need all of this?