ash_postgres v0.34.0 AshPostgres.DataLayer View Source

A postgres data layer that levereges Ecto's postgres capabilities.

Table of Contents

postgres

Postgres data layer configuration

Examples:

postgres do
  repo MyApp.Repo
  table "organizations"
end

  • :repo - Required. The repo that will be used to fetch your data. See the AshPostgres.Repo documentation for more

  • :migrate? - Whether or not to include this resource in the generated migrations with mix ash.generate_migrations The default value is true.

  • :base_filter_sql - A raw sql version of the base_filter, e.g representative = 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 is false.

  • :unique_index_names - A list of unique index names that could raise errors, or an mfa to a function that takes a changeset and returns a list of names in the format {[:affected, :keys], "name_of_constraint"} The default value is [].

  • :table - The table to store and read the resource from. Required unless polymorphic? is true.

  • :polymorphic? - 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.g

    belongs_to :polymorphic_association, PolymorphicResource, context: %{data_layer: %{table: "table"}} The default value is false.

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 a customer resource, and you want to create a schema for each customer based on their id, e.g customer_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 to 20, it would rename the schema to customer_20. Generally speaking you should avoid changing the tenant id.

  • :create? - Whether or not to automatically create a tenant when a record is created The default value is true.

  • :update? - Whether or not to automatically update the tenant name if the record is udpated The default value is true.