Packages
ash_graphql
1.3.3
1.10.0
1.9.4
1.9.3
1.9.2
1.9.1
1.9.0
1.8.5
1.8.4
1.8.3
1.8.2
1.8.1
1.8.0
1.7.17
1.7.16
1.7.15
1.7.14
1.7.13
1.7.12
1.7.11
1.7.10
1.7.9
1.7.8
1.7.7
1.7.6
1.7.5
1.7.4
1.7.3
1.7.2
1.7.1
1.7.0
1.6.0
1.5.1
1.5.0
1.4.7
1.4.6
1.4.5
1.4.4
1.4.3
1.4.2
1.4.1
1.4.0
1.3.4
1.3.3
1.3.2
1.3.1
1.3.0
1.2.1
1.2.0
1.1.1
1.1.0
1.0.1
1.0.0
1.0.0-rc.5
1.0.0-rc.4
retired
1.0.0-rc.3
1.0.0-rc.2
1.0.0-rc.1
1.0.0-rc.0
0.28.1
0.28.0
0.27.1
0.27.0
0.26.9
0.26.8
0.26.7
0.26.6
0.26.5
0.26.4
0.26.3
0.26.2
0.26.0
0.25.13
0.25.12
0.25.10
0.25.9
0.25.8
0.25.7
0.25.6
0.25.5
0.25.4
0.25.3
0.25.2
0.25.1
0.25.0
0.24.1
0.24.0
0.23.3
0.23.2
0.23.1
0.23.0
0.22.13
0.22.12
0.22.11
0.22.10
0.22.9
0.22.8
0.22.7
0.22.6
0.22.4
0.22.3
0.22.2
0.22.1
0.22.0
0.21.0
retired
0.20.5
0.20.4
0.20.3
0.20.2
0.20.1
0.20.0-rc.3
0.20.0-rc.2
0.20.0-rc.1
0.20.0-rc.0
0.19.0
0.18.0-rc0
0.17.5
0.17.5-rc0
0.17.4
0.17.2
0.17.1
0.17.0
0.16.28
0.16.27
0.16.26
0.16.25
0.16.24
0.16.23
0.16.22
0.16.21
0.16.20
0.16.18-rc5
0.16.18-rc4
0.16.18-rc3
0.16.18-rc2
0.16.18-rc1
0.16.18-rc0
0.16.17
0.16.16
0.16.15
0.16.14
0.16.13
0.16.12
0.16.11
0.16.10
0.16.9
0.16.8
0.16.7
0.16.6
0.16.5
0.16.4
0.16.3
0.16.2
0.16.1
0.16.0
0.15.10
0.15.9
0.15.8
0.15.7
0.15.6
0.15.5
0.15.4
0.15.3
0.15.2
0.15.1
0.15.0
0.14.1
0.14.0
0.13.1
0.13.0
0.12.5
0.12.4
0.12.3
0.12.1
0.12.0
0.10.0
0.9.5
0.9.4
0.9.3
0.9.2
0.9.1
0.9.0
0.8.0
0.7.5
0.7.4
0.7.3
0.7.2
0.7.1
0.7.0
0.6.3
0.6.2
0.6.1
0.6.0
0.5.0
0.4.0
0.3.2
0.3.1
0.3.0
0.2.1
0.2.0
0.1.3
0.1.2
The extension for building GraphQL APIs with Ash
Current section
Files
Jump to
Current section
Files
documentation/topics/upgrade.md
# Upgrading to 1.0
AshGraphql 1.0 is a major release that introduces 3.0 support as well as a few
breaking changes for AshGraphql itself.
## `:datetime` is now the default representation for datetimes
For backwards compatibility, pre-1.0 we had users configure `:utc_datetime_type` to `:datetime` as part of the getting started guide. This is now the default. The configuration remains, but has been renamed. It was improperly `config :ash, :utc_datetime_type`, and it is now `config :ash_graphql, :utc_datetime_type`. If you are a user who is relying on the original behavior that had it default to `:naive_datetime`, you can set the following configuration:
```elixir
config :ash_graphql, :utc_datetime_type, :naive_datetime
```
Otherwise, if you have the following in your config, you can remove it.
```elixir
config :ash, :utc_datetime_type, :datetime
```
## `allow_non_null_mutation_arguments?` is now `true` always
You can remove this code from your config.
```elixir
config :ash_graphql, :allow_non_null_mutation_arguments?, true
```
Pre 1.0, the `input` argument for mutations was always allowed to be `null`. In 1.0, it will be required if there are any non-null inputs inside of the object. You may need to address clients that are expecting to be able to send `null`. Even if they _were_ sending `null` in those cases, it would have been an error, so it is unlikely that you will have to make any changes here.
---
## Automagic atom/union/map types are no more
Pre 1.0: AshGraphql automatically generated types for attributes/arguments that were atom/union/map types, giving them a name like `postStatus`, for an attribute `status` on a resource `post`. While convenient, this incurred _significant_ internal complexity, and had room for strange ambiguity. For example, if you had two actions, that each had an argument called `:status`, and that `:status` was an enum with different values, you would get a conflict at compile time due to conflicting type names.
### What you'll need to change
AshGraphql will now _only_ generate types for types defined using `Ash.Type.NewType` or `Ash.Type.Enum`. For example, if you had:
```elixir
attribute :post_status, :atom, constraints: [one_of: [:active, :archived]]
```
in 3.0 this attribute would display as a `:string`. To fix this, you would define an `Ash.Type.Enum`:
```elixir
defmodule MyApp.PostStatus do
use Ash.Type.Enum, values: [:active, :archived]
def graphql_type(_), do: :post_status
def graphql_input_type(_), do: :post_status
end
```
Then you could use it in your attribute:
```elixir
attribute :post_status, MyApp.PostStatus
```
The same goes for map types with the `:fields` constraint, as well as union types, except you must define those using `Ash.Type.NewType`. For example:
```elixir
attribute :scale, :union, constraints: [
types: [
whole: [
type: :integer
],
fractional: [
type: :decimal
]
]
]
```
Here you would get a compile error, indicating that we cannot determine a type for `:union`. To resolve this, you would define an `Ash.Type.NewType`, like so:
```elixir
defmodule MyApp.Scale do
use Ash.Type.NewType, subtype_of: :union, constraints: [
types: [
whole: [
type: :integer
],
fractional: [
type: :decimal
]
]
]
def graphql_type(_), do: :scale
def graphql_input_type(_), do: :scale
end
```
Then you could use it in your application like so:
```elixir
attribute :scale, MyApp.Scale
```
---
## The `managed_relationships.auto?` option now defaults to `true`
Pre 1.0, you would need to either configure managed_relationships manually, for example:
```elixir
managed_relationships do
managed_relationship :create, :comments
end
```
Or set `auto?` to `true`, which would derive appropriate configurations for any action that had arguments with corresponding `manage_relationship` changes for them. This is unnecessarily verbose and there isn't really a time where you wouldn't want an input type derived for an argument that uses `change manage_relationship`, so the default for `auto?` is now `true`. This only affects arguments who's type is `:map`, or `{:array, :map}`.
A new option has been added to `managed_relationship` to allow you to bypass this type generation if necessary:
```elixir
managed_relationships do
managed_relationship :create, :comments, ignore?: true
end
```
## `Ash.Api` is now `Ash.Domain` in Ash 3.0
Your Absinthe schema file (ie. `MyApp.Schema`) will need all references to `api` updated to be `domain`. eg.
```elixir
@domains [MyApp.Domain1, MyApp.Domain2]
use AshGraphql, domains: @domains
```