View Source AshPostgres.DataLayer (ash_postgres v1.3.28)
A postgres data layer that leverages Ecto's postgres capabilities.
dsl-documentation
DSL Documentation
index
Index
- postgres
- custom_indexes
- index
- custom_statements
- statement
- manage_tenant
- references
- reference
- check_constraints
- check_constraint
- custom_indexes
docs
Docs
postgres
postgres
Postgres data layer configuration
- custom_indexes
- index
- custom_statements
- statement
- manage_tenant
- references
- reference
- check_constraints
- check_constraint
Examples:
postgres do
repo MyApp.Repo
table "organizations"
end
:repo
(atom/0
) - Required. The repo that will be used to fetch your data. See theAshPostgres.Repo
documentation for more:migrate?
(boolean/0
) - Whether or not to include this resource in the generated migrations withmix ash.generate_migrations
The default value istrue
.:migration_types
(keyword/0
) - A keyword list of attribute names to the ecto migration type that should be used for that attribute. Only necessary if you need to override the defaults. The default value is[]
.:migration_defaults
(keyword/0
) - A keyword list of attribute names to the ecto migration default that should be used for that attribute. Only necessary if you need to override the defaults.
The string you use will be placed verbatim in the migration. Use fragments likefragment(\\"now()\\")
, or fornil
, use\\"nil\\"
. The default value is[]
.:base_filter_sql
(String.t/0
) - A raw sql version of the base_filter, e.grepresentative = true
. Required if trying to create a unique constraint on a resource with a base_filter:skip_unique_indexes
- Skip generating unique indexes when generating migrations The default value isfalse
.:unique_index_names
(term/0
) - A list of unique index names that could raise errors, or an mfa to a function that takes a changeset and returns the list. Must be in the format{[:affected, :keys], "name_of_constraint"}
or{[:affected, :keys], "name_of_constraint", "custom error message"}
Note that this is not used to rename the unique indexes created fromidentities
. Useidentity_index_names
for that. This is used to tell ash_postgres about unique indexes that exist in the database that it didn't create. The default value is[]
.:exclusion_constraint_names
(term/0
) - A list of exclusion constraint names that could raise errors. Must be in the format{:affected_key, "name_of_constraint"}
or{:affected_key, "name_of_constraint", "custom error message"}
The default value is[]
.:identity_index_names
(term/0
) - A keyword list of identity names to the unique index name that they should use when being managed by the migration generator. The default value is[]
.:foreign_key_names
(term/0
) - A list of foreign keys that could raise errors, or an mfa to a function that takes a changeset and returns the list. Must be in the format{:key, "name_of_constraint"}
or{:key, "name_of_constraint", "custom error message"}
The default value is[]
.:migration_ignore_attributes
(list ofatom/0
) - A list of attributes that will be ignored when generating migrations. The default value is[]
.:table
(String.t/0
) - The table to store and read the resource from. Required unlesspolymorphic?
is true.
If this is changed, the migration generator will not remove the old table.:schema
(String.t/0
) - The schema that the table is located in. Multitenancy supersedes this, so this acts as the schema in the cases thatglobal?: true
is set. If this is changed, the migration generator will not remove the old table in the old schema.:polymorphic?
(boolean/0
) - Declares this resource as polymorphic.
Polymorphic resources cannot be read or updated unless the table is provided in the query/changeset context.
For example:PolymorphicResource |> Ash.Query.set_context(%{data_layer: %{table: "table"}}) |> MyApi.read!()
When relating to polymorphic resources, you'll need to use the
context
option on relationships, e.gbelongs_to :polymorphic_association, PolymorphicResource, context: %{data_layer: %{table: "table"}} The default value is `false`.
custom_indexes
custom_indexes
A section for configuring indexes to be created by the migration generator.
In general, prefer to use identities
for simple unique constraints. This is a tool to allow
for declaring more complex indexes.
Examples:
custom_indexes do
index [:column1, :column2], unique: true, where: "thing = TRUE"
end
index
Add an index to be managed by the migration generator.
Examples:
index ["column", "column2"], unique: true, where: "thing = TRUE"
:fields
- The fields to include in the index.:name
(String.t/0
) - the name of the index. Defaults to "#{table}_#{column}_index".:unique
(boolean/0
) - indicates whether the index should be unique. The default value isfalse
.:concurrently
(boolean/0
) - indicates whether the index should be created/dropped concurrently. The default value isfalse
.:using
(String.t/0
) - configures the index type.:prefix
(String.t/0
) - specify an optional prefix for the index.:where
(String.t/0
) - specify conditions for a partial index.:message
(String.t/0
) - A custom message to use for unique indexes that have been violated:include
(list ofString.t/0
) - specify fields for a covering index. This is not supported by all databases. For more information on PostgreSQL support, please read the official docs.
custom_statements
custom_statements
A section for configuring custom statements to be added to migrations.
Changing custom statements may require manual intervention, because Ash can't determine what order they should run
in (i.e if they depend on table structure that you've added, or vice versa). As such, any down
statements we run
for custom statements happen first, and any up
statements happen last.
Additionally, when changing a custom statement, we must make some assumptions, i.e that we should migrate
the old structure down using the previously configured down
and recreate it.
This may not be desired, and so what you may end up doing is simply modifying the old migration and deleting whatever was generated by the migration generator. As always: read your migrations after generating them!
Examples:
custom_statements do
# the name is used to detect if you remove or modify the statement
statement :pgweb_idx do
up "CREATE INDEX pgweb_idx ON pgweb USING GIN (to_tsvector('english', title || ' ' || body));"
down "DROP INDEX pgweb_idx;"
end
end
statement
Add a custom statement for migrations.
Examples:
statement :pgweb_idx do
up "CREATE INDEX pgweb_idx ON pgweb USING GIN (to_tsvector('english', title || ' ' || body));"
down "DROP INDEX pgweb_idx;"
end
:name
(atom/0
) - Required. The name of the statement, must be unique within the resource:code?
(boolean/0
) - Whether the provided up/down should be treated as code or sql strings.
By default, we place the strings inside of ecto migration'sexecute/1
function and assume they are sql. Use this option if you want to provide custom elixir code to be placed directly in the migrations The default value isfalse
.:up
(String.t/0
) - Required. How to create the structure of the statement:down
(String.t/0
) - Required. How to tear down the structure of the statement
manage_tenant
manage_tenant
Configuration for the behavior of a resource that manages a tenant
Examples:
manage_tenant do
template ["organization_", :id]
create? true
update? false
end
:template
- Required. A template that will cause the resource to create/manage the specified schema.
Use this if you have a resource that, when created, it should create a new tenant for you. For example, if you have acustomer
resource, and you want to create a schema for each customer based on their id, e.gcustomer_10
set this option to["customer_", :id]
. Then, when this is created, it will create a schema called["customer_", :id]
, and run your tenant migrations on it. Then, if you were to change that customer's id to20
, it would rename the schema tocustomer_20
. Generally speaking you should avoid changing the tenant id.:create?
(boolean/0
) - Whether or not to automatically create a tenant when a record is created The default value istrue
.:update?
(boolean/0
) - Whether or not to automatically update the tenant name if the record is udpated The default value istrue
.
references
references
A section for configuring the references (foreign keys) in resource migrations.
This section is only relevant if you are using the migration generator with this resource. Otherwise, it has no effect.
Examples:
references do
reference :post, on_delete: :delete, on_update: :update, name: "comments_to_posts_fkey"
end
:polymorphic_on_delete
- For polymorphic resources, configures the on_delete behavior of the automatically generated foreign keys to source tables. Valid values are :delete, :nilify, :nothing, :restrict:polymorphic_on_update
- For polymorphic resources, configures the on_update behavior of the automatically generated foreign keys to source tables. Valid values are :update, :nilify, :nothing, :restrict:polymorphic_name
- For polymorphic resources, configures the on_update behavior of the automatically generated foreign keys to source tables. Valid values are :update, :nilify, :nothing, :restrict
reference
Configures the reference for a relationship in resource migrations.
Keep in mind that multiple relationships can theoretically involve the same destination and foreign keys.
In those cases, you only need to configure the reference
behavior for one of them. Any conflicts will result
in an error, across this resource and any other resources that share a table with this one. For this reason,
instead of adding a reference configuration for :nothing
, its best to just leave the configuration out, as that
is the default behavior if no relationship anywhere has configured the behavior of that reference.
Examples:
reference :post, on_delete: :delete, on_update: :update, name: "comments_to_posts_fkey"
:relationship
(atom/0
) - Required. The relationship to be configured:ignore?
(boolean/0
) - If set to true, no reference is created for the given relationship. This is useful if you need to define it in some custom way:on_delete
- What should happen to records of this resource when the referenced record of the destination resource is deleted.
The difference between:nothing
and:restrict
is subtle and, if you are unsure, choose:nothing
(the default behavior).:restrict
will prevent the deletion from happening before the end of the database transaction, whereas:nothing
allows the transaction to complete before doing so. This allows for things like deleting the destination row and then deleting the source row.important
Important!No resource logic is applied with this operation! No authorization rules or validations take place, and no notifications are issued. This operation happens directly in the database.
This option is calledon_delete
, instead ofon_destroy
, because it is hooking into the database level deletion, not adestroy
action in your resource. Valid values are :delete, :nilify, :nothing, :restrict:on_update
- What should happen to records of this resource when the referenced destination_attribute of the destination record is update.
The difference between:nothing
and:restrict
is subtle and, if you are unsure, choose:nothing
(the default behavior).:restrict
will prevent the deletion from happening before the end of the database transaction, whereas:nothing
allows the transaction to complete before doing so. This allows for things like updating the destination row and then updating the reference as long as you are in a transaction.important-1
Important!No resource logic is applied with this operation! No authorization rules or validations take place, and no notifications are issued. This operation happens directly in the database. Valid values are :update, :nilify, :nothing, :restrict
:name
(String.t/0
) - The name of the foreign key to generate in the database. Defaults to <table>_<source_attribute>_fkey
check_constraints
check_constraints
A section for configuring the check constraints for a given table.
This can be used to automatically create those check constraints, or just to provide message when they are raised
Examples:
check_constraints do
check_constraint :price, "price_must_be_positive", check: "price > 0", message: "price must be positive"
end
check_constraint
Add a check constraint to be validated.
If a check constraint exists on the table but not in this section, and it produces an error, a runtime error will be raised.
Provide a list of attributes instead of a single attribute to add the message to multiple attributes.
By adding the check
option, the migration generator will include it when generating migrations.
Examples:
check_constraint :price, "price_must_be_positive", check: "price > 0", message: "price must be positive"
:attribute
(term/0
) - Required. The attribute or list of attributes to which an error will be added if the check constraint fails:name
(String.t/0
) - Required. The name of the constraint:message
(String.t/0
) - The message to be added if the check constraint fails:check
(String.t/0
) - The contents of the check. If this is set, the migration generator will include it when generating migrations