There is a nice table showing the available data types used in Ecto Schemas: https://hexdocs.pm/ecto/Ecto.Schema.html#module-primitive-types
But I cannot find a corresponding list that enumerates the possibilities available to an Ecto Migration. They are similar, but they are not always the same. Does anyone have such a list? And should that be a part of the docs?
Many thanks!
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.
Having some length limit by default is a good idea - if you forget validation someone can enter megabytes/gigabytes into some unassuming post title, essentially breaking everything. Better have some protection by default
Are fragments used for migrations? I’ve only seen doc example use for queries.
Thanks, @benwilson512. I actually meant as type speccing for manually defined migrations. What I’ve realised however is that using the command mix help phx.gen.schema, gives a list of the supported migration option keys:
• :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
My understanding is that this list does not change depending on the adapter anyway.
I did read the initial OP as looking for a list like this though it seems that using fragments ultimately sufficed for him so I was a bit befuddled.
Keep in mind that there are two separate things at play here (but ultimately related): in the migration you are specifying the type for the column of the database table, in the schema you are specifying the Elixir type to use in the struct.
As I said in my reply, you can pass any atom to the migration and it will be sent to the DB verbatim. For example mix phx.gen.auth uses a :citext column, which is of course not on the list (and comes from an extension).
Yes I understand, that is what the OP was talking about as I understand it.
There is a schema fields list, but he could not find a migrations field list.
© Copyright Elixir Forum | Terms | Privacy & Cookies
