Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interfaces don't enforce fields being implemented. #151

Open
phated opened this issue Mar 28, 2019 · 1 comment
Open

Interfaces don't enforce fields being implemented. #151

phated opened this issue Mar 28, 2019 · 1 comment

Comments

@phated
Copy link

phated commented Mar 28, 2019

I have a schema similar to:

let card: Schema.abstract_typ(unit, [ | `Pet]) =
  Schema.(
    interface(
      "Pet", ~doc="Interface which all pets must conform to", ~fields=_typ =>
      [
        abstract_field(
          "id",
          ~typ=non_null(string),
          ~args=Arg.[],
        ),
      ]
    )
  );

let dog =
  Schema.(
    obj("Dog", ~fields=_typ =>
      [
        field(
          "name",
          ~typ=non_null(string),
          ~args=Arg.[],
          ~resolve=(ctx, dog) => dog.name,
        ),
      ]
    )
  );

let cat =
  Schema.(
    obj("Cat", ~fields=_typ =>
      [
        field(
          "name",
          ~typ=non_null(string),
          ~args=Arg.[],
          ~resolve=(ctx, cat) => cat.name,
        ),
      ]
    )
  );

let dogAsPet = Schema.(add_type(pet, dog));
let catAsPet = Schema.(add_type(pet, cat));

But there are no errors produced unless I try to access the id field in a query. So this query actually succeeds:

query {
  pets {
    ... on Dog {
      name
    }
    ... on Cat {
      name
    }
  }
}
@andreas
Copy link
Owner

andreas commented Mar 29, 2019

This is a known limitation, but unfortunately not documented 😞Whether an object correctly implements an interface is one of the things that cannot be captured in the type system. My current plan is to "just" implement it as an exception raising runtime check when calling Schema.add_type. Although inferior to a type error, I think it's a reasonable trade-off to have an exception at schema-construction time to be exception-free at query-execution time.

Here's the TODO in the source code:

(* TODO add subtype check here *)

I'm happy to accept contributions, even if it's just a note in the README 😀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants