Problematic database column names?

Phoenix Forum Questions / Help
,
1

My first attempt using Absinthe and it’s also my first foray into GraphQL. I got things up and running for some of my resources, but the table I built for languages seems problematic, and I think it’s because how Absinthe tries to magically convert snake_case to camelCase.

When I run a query as simple as this:

  {
    languages {
      id
      name
      code6392b
    }
  }

I get a confusing error:
"message": "Cannot query field \"code6392b\" on type \"Language\". Did you mean \"code6392t\" or \"code6392b\"?"

The Ecto schema looks like this:

@primary_key {:id, :string, autogenerate: false}
schema "languages" do
  field :code_639_2t, :string, size: 3, null: false
  field :code_639_2b, :string, size: 3, null: false
  field :name, :string, size: 80, null: false
end

And that’s matched pretty closely with the Absinthe Schema :

object :language do
  field :id, :string
  field :code_639_2t, :string
  field :code_639_2b, :string
  field :name, :string
end

Can anyone tell me why I’m getting that error? I suspect (without any proof) that it has something to do with the admittedly weird column names that use numbers. (If you’re wondering, they are named to refer back to specific ISO specs).

Thanks for any tips!

2

I’ve not worked with Absinthe but I am wondering if your scheme name should be the same as your object name? ie either both pluralized or both not?

3

Absinthe converts camelCase to snake_case pretty well, but I wouldn’t assume it’d be able to correctly infer how to convert “code6392b” to “code_639_2b”, even though the error message doesn’t seem to be articulating that point very well (??).

You may need to create a custom field resolver in your schema to translate underscores. Something like:

object :language do
  # ... other fields ...
  field :code6392b, :string do
    resolve fn(language, _, _) ->
      {:ok, language.code_639_2b}
    end
  end
end

Edit: I believe it needs to be resolve/3 not resolve/2…

1 Like
4

Yes the issue you’re running into is indeed related to the autocamelization that is handled by the LanguageConventions adapter: Absinthe.Adapter.LanguageConventions — absinthe v1.7.6

It is filed as this issue:

Which states that it will be fixed in 1.5, but I’m not sure it’s still making the cut. As a workaround you can change your field name to: field :code_6392_b if I’ve read that issue correctly. Or you can use a different adapter, at work we actually use the Underscore adapter which is included in 1.5 (although we’re still on 1.4.13):
https://hexdocs.pm/absinthe/1.5.0-alpha.2/Absinthe.Adapter.Underscore.html#content

5

It seems that there is also a name option for the field macro however it is not in the documentation:

field :code_639_2b, :string, name: "code6392b"
6 Likes
6

That little name option fixed it! Thank you!

Oh - we’ve got queries for both singular resources and plural collections. Makes it a bit easier to think about.

7

Yes, that’s better because it doesn’t affect the rest of your graph (like an adapter would). Didn’t realize that name would work there, someone should submit a doc PR if it’s not already well documented in 1.5 :slight_smile:

8

I supplied this PR based on our thread: https://github.com/absinthe-graphql/absinthe/pull/679

I wanted to include an example of how to deprecate a column, but I could not see how to do that… using the deprecation option didn’t seem to make any difference to Graphiql introspection.

2 Likes