mirror of
https://github.com/ash-project/ash.git
synced 2024-09-20 05:23:03 +12:00
docs: Fix typos in docs (#1045)
This commit is contained in:
parent
2a940cdecc
commit
18af9d7704
8 changed files with 17 additions and 17 deletions
|
@ -39,7 +39,7 @@ end
|
||||||
|
|
||||||
Changing attributes in this way makes them safer to use in concurrent environments, and is typically more performant than doing it manually in memory.
|
Changing attributes in this way makes them safer to use in concurrent environments, and is typically more performant than doing it manually in memory.
|
||||||
|
|
||||||
> ### atomics are not stored with other changes {: .warning}
|
> ### Atomics are not stored with other changes {: .warning}
|
||||||
>
|
>
|
||||||
> While we recommend using atomics wherever possible, it is important to note that they are stored in their own map in the changeset, i.e `changeset.atomics`, meaning if you need to do something later in the action with the new value for an attribute, you won't be able to access the new value. This is because atomics are evaluated in the data layer.
|
> While we recommend using atomics wherever possible, it is important to note that they are stored in their own map in the changeset, i.e `changeset.atomics`, meaning if you need to do something later in the action with the new value for an attribute, you won't be able to access the new value. This is because atomics are evaluated in the data layer.
|
||||||
|
|
||||||
|
|
|
@ -209,7 +209,7 @@ Ash.Changeset.for_create!(.., tenant: current_tenant, actor: current_user)
|
||||||
Ash.Query.for_read(.., tenant: current_tenant, actor: current_user)
|
Ash.Query.for_read(.., tenant: current_tenant, actor: current_user)
|
||||||
```
|
```
|
||||||
|
|
||||||
### the `Domain` of a resource must now be known when constructing a changeset, query or action input
|
### The `Domain` of a resource must now be known when constructing a changeset, query or action input
|
||||||
|
|
||||||
In order to honor rules on the `Domain` module about authorization and timeouts, we have to know the `Domain` when building the changeset.
|
In order to honor rules on the `Domain` module about authorization and timeouts, we have to know the `Domain` when building the changeset.
|
||||||
|
|
||||||
|
|
|
@ -107,6 +107,6 @@ If the calculation uses an expression, you can also filter and sort on it like s
|
||||||
|
|
||||||
```elixir
|
```elixir
|
||||||
query
|
query
|
||||||
|> Ash.Query.filter(full_name(separator: ","))
|
|> Ash.Query.filter(full_name(separator: " ") == "Zach Daniel")
|
||||||
|> Ash.Query.sort(full_name: {%{separator: ","}, :asc})
|
|> Ash.Query.sort(full_name: {%{separator: " "}, :asc})
|
||||||
```
|
```
|
||||||
|
|
|
@ -89,7 +89,7 @@ actions do
|
||||||
end
|
end
|
||||||
```
|
```
|
||||||
|
|
||||||
Or you can use the global changes block to apply to all actions of a given type. Where statements can be used in both cases. Use `on` to determine the types of actions the validation runs on. By default, it only runs on create an update actions.
|
Or you can use the global changes block to apply to all actions of a given type. Where statements can be used in both cases. Use `on` to determine the types of actions the validation runs on. By default, it only runs on create and update actions.
|
||||||
|
|
||||||
```elixir
|
```elixir
|
||||||
changes do
|
changes do
|
||||||
|
@ -99,7 +99,7 @@ changes do
|
||||||
end
|
end
|
||||||
```
|
```
|
||||||
|
|
||||||
The changes section allows you to add validations across multiple actions of a changeset.
|
The changes section allows you to add changes across multiple actions of a changeset.
|
||||||
|
|
||||||
> ### Running on destroy actions {: .warning}
|
> ### Running on destroy actions {: .warning}
|
||||||
>
|
>
|
||||||
|
@ -181,9 +181,9 @@ defmodule MyApp.Changes.Slugify do
|
||||||
def batch_change(changeset, opts, context) do
|
def batch_change(changeset, opts, context) do
|
||||||
# here we could run queries or do common work required
|
# here we could run queries or do common work required
|
||||||
# for a given batch of changesets.
|
# for a given batch of changesets.
|
||||||
# in this example, however, we just return the changests with
|
# in this example, however, we just return the changesets with
|
||||||
# the change logic applied.
|
# the change logic applied.
|
||||||
Enum.map(changesets, &change(&1, opts, contextk)
|
Enum.map(changesets, &change(&1, opts, context))
|
||||||
end
|
end
|
||||||
end
|
end
|
||||||
```
|
```
|
||||||
|
|
|
@ -1,6 +1,6 @@
|
||||||
# Embedded Resources
|
# Embedded Resources
|
||||||
|
|
||||||
Embedded resources are stored as maps in attributes of other resources. They are great for storing structured data, and support a whole range of useful features that resources support. For example, you can have calculations, validations, policies and even relationships on embedded resources.Here is an example of a simple embedded resource:
|
Embedded resources are stored as maps in attributes of other resources. They are great for storing structured data, and support a whole range of useful features that resources support. For example, you can have calculations, validations, policies and even relationships on embedded resources. Here is an example of a simple embedded resource:
|
||||||
|
|
||||||
```elixir
|
```elixir
|
||||||
defmodule MyApp.Profile do
|
defmodule MyApp.Profile do
|
||||||
|
@ -14,7 +14,7 @@ defmodule MyApp.Profile do
|
||||||
end
|
end
|
||||||
```
|
```
|
||||||
|
|
||||||
> ### embedded resources can't do everything {: .info}
|
> ### Embedded resources can't do everything {: .info}
|
||||||
> Embedded resources cannot have aggregates, or expression calculations that rely on data-layer-specific capabilities.
|
> Embedded resources cannot have aggregates, or expression calculations that rely on data-layer-specific capabilities.
|
||||||
|
|
||||||
## Adding embedded resource attributes
|
## Adding embedded resource attributes
|
||||||
|
@ -51,7 +51,7 @@ end
|
||||||
If you manually supply instances of the embedded structs, the structs you provide are used with no validation. For example:
|
If you manually supply instances of the embedded structs, the structs you provide are used with no validation. For example:
|
||||||
|
|
||||||
```elixir
|
```elixir
|
||||||
Ash.Changeset.for_update(user, :update, %{profile: %MyApp.Profile{first_name: "first_name", last_name: "last_name}})
|
Ash.Changeset.for_update(user, :update, %{profile: %MyApp.Profile{first_name: "first_name", last_name: "last_name"}})
|
||||||
```
|
```
|
||||||
|
|
||||||
However, you can also treat embedded resources like regular resources that can be "created", "updated", and "destroyed".
|
However, you can also treat embedded resources like regular resources that can be "created", "updated", and "destroyed".
|
||||||
|
|
|
@ -10,7 +10,7 @@ A notifier is a simple extension that must implement a single callback `notify/1
|
||||||
|
|
||||||
For more information on creating a DSL extension to configure your notifier, see the docs for `Spark.Dsl.Extension`.
|
For more information on creating a DSL extension to configure your notifier, see the docs for `Spark.Dsl.Extension`.
|
||||||
|
|
||||||
> ### notifier performance {: .warning}
|
> ### Notifier performance {: .warning}
|
||||||
>
|
>
|
||||||
> Notifiers should not do intensive synchronous work. If any heavy work needs to be done, they should delegate to something else to handle the notification, like sending it to a GenServer or GenStage.
|
> Notifiers should not do intensive synchronous work. If any heavy work needs to be done, they should delegate to something else to handle the notification, like sending it to a GenServer or GenStage.
|
||||||
|
|
||||||
|
|
|
@ -293,7 +293,7 @@ unnecessary `organization_id` field on `Employee`. The same works in reverse: `h
|
||||||
allows relating the employee to their organization.
|
allows relating the employee to their organization.
|
||||||
|
|
||||||
|
|
||||||
> ### caveats for using `no_attributes?` {: .warning}
|
> ### Caveats for using `no_attributes?` {: .warning}
|
||||||
>
|
>
|
||||||
> 1. You can still manage relationships from one to the other, but "relate" and "unrelate" will have no effect, because there are no fields to change.
|
> 1. You can still manage relationships from one to the other, but "relate" and "unrelate" will have no effect, because there are no fields to change.
|
||||||
> 2. Loading the relationship on a list of resources will not behave as expected in all circumstances involving multitenancy. For example, if you get a list of `Organization` and then try to load `employees`, you would need to set a single tenant on the load query, meaning you'll get all organizations back with the set of employees from one tenant. This could eventually be solved, but for now it is considered an edge case.
|
> 2. Loading the relationship on a list of resources will not behave as expected in all circumstances involving multitenancy. For example, if you get a list of `Organization` and then try to load `employees`, you would need to set a single tenant on the load query, meaning you'll get all organizations back with the set of employees from one tenant. This could eventually be solved, but for now it is considered an edge case.
|
||||||
|
@ -307,7 +307,7 @@ Manual relationships allow you to express complex or non-typical relationships b
|
||||||
|
|
||||||
In our Helpdesk example, we'd like to have a way to find tickets
|
In our Helpdesk example, we'd like to have a way to find tickets
|
||||||
|
|
||||||
In the `Rep?` resource, define a `has_many` relationship as `manual` and point to the module where
|
In the `Representative` resource, define a `has_many` relationship as `manual` and point to the module where
|
||||||
it will be implemented.
|
it will be implemented.
|
||||||
|
|
||||||
```elixir
|
```elixir
|
||||||
|
@ -406,7 +406,7 @@ With this, those arguments can be used in action input:
|
||||||
|
|
||||||
```elixir
|
```elixir
|
||||||
post
|
post
|
||||||
|> Ash.Changeset.for_update(:update, tags: [tag1.id, tag2.id], add_comment: %{text: "comment text"})
|
|> Ash.Changeset.for_update(:update, %{tags: [tag1.id, tag2.id], add_comment: %{text: "comment text"}})
|
||||||
|> Ash.update!()
|
|> Ash.update!()
|
||||||
```
|
```
|
||||||
|
|
||||||
|
@ -425,7 +425,7 @@ And then you could use it like so:
|
||||||
|
|
||||||
```elixir
|
```elixir
|
||||||
post
|
post
|
||||||
|> Ash.Changeset.for_update(:update, tags: [tag1.id, tag2.id], add_comment: "comment text")
|
|> Ash.Changeset.for_update(:update, %{tags: [tag1.id, tag2.id], add_comment: "comment text"})
|
||||||
|> Ash.update!()
|
|> Ash.update!()
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
|
@ -92,7 +92,7 @@ actions do
|
||||||
end
|
end
|
||||||
```
|
```
|
||||||
|
|
||||||
Or you can use the global validations block to validate on all actions of a given type. Where statements can be used in either. Note the warning about runningo on destroy actions below.
|
Or you can use the global validations block to validate on all actions of a given type. Where statements can be used in either. Note the warning about running on destroy actions below.
|
||||||
|
|
||||||
```elixir
|
```elixir
|
||||||
validations do
|
validations do
|
||||||
|
|
Loading…
Reference in a new issue