Ecto Migration Field Types

This?

That’s the link I meant to include in my post (now edited). That lists the data types for SCHEMAS. It’s similar, but not the same for MIGRATIONS. Thus the post. Where is there a similar list for types available within migrations?

This depends on the underlying database adapter. You can always use fragment for the type as well and specify anything you like.

I figured out how to take advantage of PostGreSQL’s inet data type following Pedro’s excellent article:

add :ip, :inet, null: false, default: fragment("'0.0.0.0'::inet")

Note that you can just put whatever PostGres data type as the 2nd argument (no need to use fragment there). The fragment macro was however useful to supply a default argument for that field.

There is still the correlating types used by the schema, but this gets me so I’m able to create the database the way I want. Thanks all!

The list of types defined for Postgres is in postgrex extensions.

Seems :string is not included in this list. I know bit_string is here, but the form used in ecto migrations is :string. Just an FYI for other readers.

There is a mapping from Ecto aliases (like :string) to database types. For Postgres I believe that mapping is right here. So as you can see :string is converted to :varchar. If the type is unknown it is converted to a string and then sent verbatim, which is why you can use any db-specific type (like :citext) even if it’s not present there.

Note that the :string type is not equivalent to :text with Ecto/Postgres, because for some reason :string actually becomes varchar(255) - that is to say it has a limit of 255 characters.

I have no idea where that default size is set (or why, for that matter).

That’s a great link you provided.

One might have to rummage through (ctlr f) for mappings for things like :text. It seems the preference is to phx.gen.schema, as access to full schema mappings is readily available.

255 is an old suggested default size for varchar, there were reason for it at the time, there’s no great reason to continue to use it anymore. For Postgres, unless you want to enforce some hard limit on the size of a string field, it’s best to use text as your default character field type.

Another reason to use text is that Postgres string functions typically define their parameters as text, and hence you’re less likely to get type mismatch errors on them. varchar is treated somewhat as a domain over text and hence not exactly the same.