Not handling Ash.NaiveDatetime
dantswain opened this issue · comments
Hi! I have a resource with a :naive_datetime
type:
defmodule MyApp.SomeResource do
...
attributes do
...
attribute :scheduled_at, :naive_datetime
end
graphql do
type :some_resource
end
end
At compile time that results in an error:
** (FunctionClauseError) no function clause matching in AshGraphql.Resource.get_specific_field_type/3
The following arguments were given to AshGraphql.Resource.get_specific_field_type/3:
# 1
Ash.Type.NaiveDatetime
# 2
%Ash.Resource.Attribute{name: :received_at, type: Ash.Type.NaiveDatetime, allow_nil?: true, generated?: false, primary_key?: false, private?: false, writable?: true, always_select?: false, default: nil, update_default: nil, description: nil, source: :received_at, match_other_defaults?: false, sensitive?: false, filterable?: true, constraints: []}
# 3
MyApp.SomeResource
It seems the naive_datetime built-in type is not being handled. I was able to fix it by manually specifying the type:
graphql do
type :some_resource
attribute_types [scheduled_at: :naive_datetime]
end
And then in MyApp.Schema
i also need to import_types Absinthe.Type.Custom
(which I was already doing).
It also seems that graphql fields are not being generated for the created/updated timestamps, which is unexpected.
By default, the created_at
and updated_at
timestamps are private. You can use timestamps(private?: false)
to change that.
As for the :naive_datetime
, the fact that it requires the absinthe custom types makes it a bit tough to include by default. Wonder what the best way to handle that is...I guess we could just adjust the getting started guide to include importing the absinthe custom types?
Ahhh yep the private flag explains the missing time stamps.
What you said about the absinthe custom types makes sense. Documentation would definitely help like you said, maybe also having it throw a specific error pointing the user in the right direction similar to what it does for utc? Those sorts of messages are always really really helpful to me personally.
Another idea might be to allow the user to provide custom default type mappings somehow - i.e., "when you see this ecto type, use this graphql type"?
So you can do that with a custom type by defining def graphql_type(constraints), do: :graphql_type
, but AshGraphql
should provide implementations for all the builtin types.
I've pushed a fix up. Checked the code, we automatically import the custom types, so I've just added the type conversion. I will be adding a nicer error message as well :)