Polymorphic field in Absinthe

Questions / Help
, ,
1

Hi all! My GraphQL education is still in a fairly nascent stage and I’ve run into an issue that seems like it should be easy to solve, yet I can’t figure out a solution. This makes me think I have a flawed mental model and/or a suboptimal implementation.

Here’s a brief rundown of the relevant pieces of my application, with some of my possibly incorrect understandings made explicit:

  • A PostgreSQL table, datapoints, that contains a payload column (among others) which is set to the map type in my Ecto migration. As far as I understand, this configuration means that Ecto will create that column as jsonb and encode/decode as appropriate.
  • The payload map should contain a :value key which is one of data shapes: a boolean value, a string, or a list of strings. I am enforcing this rule via various strategies which I can’t imagine have any bearing on my GraphQL conundrum.
  • An Elixir module that defines an Ecto schema for the datapoints table with field(:payload, :map).
  • An Elixir module that defines an Absinthe schema. It defines an object, :datapoint, as part of the root query object.

My issue comes into play when I try to define the :payload field on the :datapoint object in my schema, i.e.:

object :datapoint do
  field(:id, :id)
  field(:name, :string)
  field(:type, :string)
  field(:payload, # ??? #)
end

How should I tell Absinthe that this field should be one of type :boolean, :string, or list_of(:string)? I’ve gone down quite the rabbit hole of unions, interfaces, and custom scalars, but nothing seems quite right… I can share more code upon request, but I don’t want to start this off with a giant wall of text, and I’m hoping I’m missing something simple. :grimacing:

Any help is very greatly appreciated!

3 Likes
2

Hey @ngscheurich!

The GraphQL type system only permits unions between objects. This leads to the following slightly cumbersome solution:

object :boolean_value do
  field :value, non_null(:boolean)
end

object :string_value do
  field :value, non_null(:string)
end

object :string_list do
  field :value, list_of(:string)
end

union :payload do
  types [:string_value, :string_list, :boolean_value]

  resolve_type fn payload ->
    #exercise for the reader
  end
end
6 Likes
3

Thanks for the quick response, @benwilson512!

So, it seems like I was sort of on the right path, which is a nice sanity check. Here’s the code I was working on:

 object :boolean_payload do
    field(:value, :boolean)
  end

  object :string_payload do
    field(:value, :string)
  end

  object :list_payload do
    field(:value, list_of(:string))
  end

  union :payload do
    types([:boolean_payload, :string_payload, :list_payload])
    resolve_type(&resolve_payload_value/2)
  end

  defp resolve_payload_value(value, _) when is_boolean(value),
    do: :boolean_payload

  defp resolve_payload_value(value, _) when is_binary(value),
    do: :string_payload

  defp resolve_payload_value(value, _) when is_list(value),
    do: :list_payload

My confusion is around how to write the query, e.g., what I should sub-select on payload here:

query ($elderId: String!, $datapointName: String!, $count: Int) {
  datapointsForElder(elderId: $elderId, datapointName: $datapointName, count: $count) {
    name,
  	type,
    payload {
      ???
    }
  }
}

I’m looking at inline fragments at the moment, like ... on BooleanPayload { value } but something about that doesn’t seem quite right…

It seems like I have more of GraphQL problem, so I’ll study up on that part of the equation—any advice is, of course, appreciated though.

P. S. Looking forward to seeing you at The Big Elixir this week!

4 Likes
4

Once again you’re actually 100% on the right path. The GraphQL type system has your back here actually, because you’ve got 3 completely different return types, so it forces you to articulate the branches you want to handle:

query ($elderId: String!, $datapointName: String!, $count: Int) {
  datapointsForElder(elderId: $elderId, datapointName: $datapointName, count: $count) {
    name,
  	type,
    payload {
      ... on BooleanPayload { __typename value }
      ... on StringPayload { __typename value }
      ... on ListPayload { __typename value }
    }
  }
}

The addition of __typename is handy since it will annotate in the result JSON which outcome it was.

And yeah! I’m looking forward to the conference as well, please stop by and say hi!

10 Likes
5

I have a similar issue. The MyXQL returns zero dates (0000-00-00) as atom :zero_date . So the field could be either :date type or :string? Right now I try to fix the data in the legacy system. Or I should create a new Custom Type.

** (ArgumentError) cannot load `:zero_date` as type :date for field :final_backshop_date in %App.Member
(ecto) lib/ecto/repo/queryable.ex:345: Ecto.Repo.Queryable.struct_load!/6
(ecto) lib/ecto/repo/queryable.ex:201: anonymous fn/5 in Ecto.Repo.Queryable.preprocessor/3
:(elixir) lib/enum.ex:1336: Enum."-map/2-lists^map/1-0-"/2
:(elixir) lib/enum.ex:1336: Enum."-map/2-lists^map/1-0-"/2
:(ecto) lib/ecto/repo/queryable.ex:158: Ecto.Repo.Queryable.execute/4
:(ecto) lib/ecto/repo/queryable.ex:18: Ecto.Repo.Queryable.all/3
:(absinthe_relay) lib/absinthe/relay/connection.ex:458: Absinthe.Relay.Connection.from_query/4
:(absinthe) lib/absinthe/resolution.ex:209: Absinthe.Resolution.call/2
6

This is really more of an ecto qustion than an Absinthe question. I’d use a custom ecto type that always returned dates instead of sometimes an atom. Your GraphQL clients shouldn’t know or care that you’re using mysql.

1 Like
7

Thank you for your suggestion.