# `mix phx.gen.schema`
[🔗](https://github.com/phoenixframework/phoenix/blob/v1.8.12/lib/mix/tasks/phx.gen.schema.ex#L1)

Generates an Ecto schema and migration.

    $ mix phx.gen.schema Blog.Post blog_posts title:string views:integer

The first argument is the schema module followed by its plural
name (used as the table name).

The generated schema above will contain:

  * a schema file in `lib/my_app/blog/post.ex`, with a `blog_posts` table
  * a migration file for the repository

The generated migration can be skipped with `--no-migration`.

## Contexts

Your schemas can be generated and added to a separate OTP app.
Make sure your configuration is properly setup or manually
specify the context app with the `--context-app` option with
the CLI.

Via config:

    config :marketing_web, :generators, context_app: :marketing

Via CLI:

    $ mix phx.gen.schema Blog.Post blog_posts title:string views:integer --context-app marketing

## Attributes

The resource fields are given using `name:type` syntax
where type are the types supported by Ecto. Omitting
the type makes it default to `:string`:

    $ mix phx.gen.schema Blog.Post blog_posts title views:integer

The following types are supported:

  * `:integer`
  * `:float`
  * `:decimal`
  * `:boolean`
  * `:map`
  * `:string`
  * `:array`
  * `:references`
  * `:text`
  * `:date`
  * `:time`
  * `:time_usec`
  * `:naive_datetime`
  * `:naive_datetime_usec`
  * `:utc_datetime`
  * `:utc_datetime_usec`
  * `:uuid`
  * `:binary`
  * `:enum`

  * `:datetime` - An alias for `:naive_datetime`

The generator also supports references, which we will properly
associate the given column to the primary key column of the
referenced table:

    $ mix phx.gen.schema Blog.Post blog_posts title user_id:references:users

This will result in a migration with an `:integer` column
of `:user_id` and create an index.

Furthermore an array type can also be given if it is
supported by your database, although it requires the
type of the underlying array element to be given too:

    $ mix phx.gen.schema Blog.Post blog_posts tags:array:string

Unique columns can be automatically generated by using:

    $ mix phx.gen.schema Blog.Post blog_posts title:unique unique_int:integer:unique

Redact columns can be automatically generated by using:

    $ mix phx.gen.schema Accounts.Superhero superheroes secret_identity:redact password:string:redact

Ecto.Enum fields can be generated by using:

    $ mix phx.gen.schema Blog.Post blog_posts title status:enum:unpublished:published:deleted

If no data type is given, it defaults to a string.

## table

By default, the table name for the migration and schema will be
the plural name provided for the resource. To customize this value,
a `--table` option may be provided. For example:

    $ mix phx.gen.schema Blog.Post posts --table cms_posts

## binary_id

Generated migration can use `binary_id` for schema's primary key
and its references with option `--binary-id`.

## primary_key

By default, the primary key in the table is called `id`. This option
allows to change the name of the primary key column. For example:

    $ mix phx.gen.schema Blog.post posts --primary-key post_id

## repo

Generated migration can use `repo` to set the migration repository
folder with option `--repo`:

    $ mix phx.gen.schema Blog.Post posts --repo MyApp.Repo.Auth

## migration_dir

Generated migrations can be added to a specific `--migration-dir` which sets
the migration folder path:

    $ mix phx.gen.schema Blog.Post posts --migration-dir /path/to/directory

## prefix

By default migrations and schemas are generated without a prefix.

For PostgreSQL this sets the "SCHEMA" (typically set via `search_path`)
and for MySQL it sets the database for the generated migration and schema.
The prefix can be used to thematically organize your tables on the database level.

A prefix can be specified with the `--prefix` flags. For example:

    $ mix phx.gen.schema Blog.Post posts --prefix blog

> #### Warning {: .warning}
>
> The flag does not generate migrations to create the schema / database.
> This needs to be done manually or in a separate migration.

## Default options

This generator uses default options provided in the `:generators`
configuration of your application. These are the defaults:

    config :your_app, :generators,
      migration: true,
      binary_id: false,
      timestamp_type: :naive_datetime,
      sample_binary_id: "11111111-1111-1111-1111-111111111111"

You can override those options per invocation by providing corresponding
switches, e.g. `--no-binary-id` to use normal ids despite the default
configuration or `--migration` to force generation of the migration.

## UTC timestamps

By setting the `:timestamp_type` to `:utc_datetime`, the timestamps
will be created using the UTC timezone. This results in a `DateTime` struct
instead of a `NaiveDateTime`. This can also be set to `:utc_datetime_usec` for
microsecond precision.

---

*Consult [api-reference.md](api-reference.md) for complete listing*
