-
Notifications
You must be signed in to change notification settings - Fork 304
/
migration.ex
1510 lines (1160 loc) · 51.3 KB
/
migration.ex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
defmodule Ecto.Migration do
@moduledoc """
Migrations are used to modify your database schema over time.
This module provides many helpers for migrating the database,
allowing developers to use Elixir to alter their storage in
a way that is database independent.
Migrations typically provide two operations: `up` and `down`,
allowing us to migrate the database forward or roll it back
in case of errors.
In order to manage migrations, Ecto creates a table called
`schema_migrations` in the database, which stores all migrations
that have already been executed. You can configure the name of
this table with the `:migration_source` configuration option.
You can configure a different database for the table that
manages your migrations by setting the `:migration_repo`
configuration option to a different repository.
Ecto also locks the `schema_migrations` table when running
migrations, guaranteeing two different servers cannot run the same
migration at the same time.
## Creating your first migration
Migrations are defined inside the "priv/REPO/migrations" where REPO
is the last part of the repository name in underscore. For example,
migrations for `MyApp.Repo` would be found in "priv/repo/migrations".
For `MyApp.CustomRepo`, it would be found in "priv/custom_repo/migrations".
Each file in the migrations directory has the following structure:
```text
NUMBER_NAME.exs
```
The NUMBER is a unique number that identifies the migration. It is
usually the timestamp of when the migration was created. The NAME
must also be unique and it quickly identifies what the migration
does. For example, if you need to track the "weather" in your system,
you can start a new file at "priv/repo/migrations/20190417140000_add_weather_table.exs"
that will have the following contents:
defmodule MyRepo.Migrations.AddWeatherTable do
use Ecto.Migration
def up do
create table("weather") do
add :city, :string, size: 40
add :temp_lo, :integer
add :temp_hi, :integer
add :prcp, :float
timestamps()
end
end
def down do
drop table("weather")
end
end
The `up/0` function is responsible to migrate your database forward.
the `down/0` function is executed whenever you want to rollback.
The `down/0` function must always do the opposite of `up/0`.
Inside those functions, we invoke the API defined in this module,
you will find conveniences for managing tables, indexes, columns,
references, as well as running custom SQL commands.
To run a migration, we generally use Mix tasks. For example, you can
run the migration above by going to the root of your project and
typing:
$ mix ecto.migrate
You can also roll it back by calling:
$ mix ecto.rollback --step 1
Note rollback requires us to say how much we want to rollback.
On the other hand, `mix ecto.migrate` will always run all pending
migrations.
In practice, we don't create migration files by hand either, we
typically use `mix ecto.gen.migration` to generate the file with
the proper timestamp and then we just fill in its contents:
$ mix ecto.gen.migration add_weather_table
## Mix tasks
As seen above, Ecto provides many Mix tasks to help developers work
with migrations. We summarize them below:
* `mix ecto.gen.migration` - generates a
migration that the user can fill in with particular commands
* `mix ecto.migrate` - migrates a repository
* `mix ecto.migrations` - shows all migrations and their status
* `mix ecto.rollback` - rolls back a particular migration
Run `mix help COMMAND` for more information on a particular command.
For a lower level API for running migrations, see `Ecto.Migrator`.
## Change
Having to write both `up/0` and `down/0` functions for every
migration is tedious and error prone. For this reason, Ecto allows
you to define a `change/0` callback with all of the code you want
to execute when migrating and Ecto will automatically figure out
the `down/0` for you. For example, the migration above can be
written as:
defmodule MyRepo.Migrations.AddWeatherTable do
use Ecto.Migration
def change do
create table("weather") do
add :city, :string, size: 40
add :temp_lo, :integer
add :temp_hi, :integer
add :prcp, :float
timestamps()
end
end
end
However, note that not all commands are reversible. Trying to rollback
a non-reversible command will raise an `Ecto.MigrationError`.
A notable command in this regard is `execute/2`, which is reversible in
`change/0` by accepting a pair of plain SQL strings. The first is run on
forward migrations (`up/0`) and the second when rolling back (`down/0`).
If `up/0` and `down/0` are implemented in a migration, they take precedence,
and `change/0` isn't invoked.
## Field Types
The [Ecto primitive types](https://hexdocs.pm/ecto/Ecto.Schema.html#module-primitive-types) are mapped to the appropriate database
type by the various database adapters. For example, `:string` is
converted to `:varchar`, `:binary` to `:bytea` or `:blob`, and so on.
In particular, note that:
* the `:string` type in migrations by default has a limit of 255 characters.
If you need more or less characters, pass the `:size` option, such
as `add :field, :string, size: 10`. If you don't want to impose a limit,
most databases support a `:text` type or similar
* the `:binary` type in migrations by default has no size limit. If you want
to impose a limit, pass the `:size` option accordingly. In MySQL, passing
the size option changes the underlying field from "blob" to "varbinary"
Any other type will be given as is to the database. For example, you
can use `:text`, `:char`, or `:varchar` as types. Types that have spaces
in their names can be wrapped in double quotes, such as `:"int unsigned"`,
`:"time without time zone"`, etc.
## Executing and flushing
Instructions inside of migrations are not executed immediately. Instead
they are performed after the relevant `up`, `change`, or `down` callback
terminates.
However, in some situations you may want to guarantee that all of the
previous steps have been executed before continuing. This is useful when
you need to apply a set of changes to the table before continuing with the
migration. This can be done with `flush/0`:
def up do
...
flush()
...
end
However `flush/0` will raise if it would be called from `change` function when doing a rollback.
To avoid that we recommend to use `execute/2` with anonymous functions instead.
For more information and example usage please take a look at `execute/2` function.
## Repo configuration
### Migrator configuration
These options configure how the underlying migration engine works:
* `:migration_source` - Version numbers of migrations will be saved in a
table named `schema_migrations` by default. You can configure the name of
the table via:
config :app, App.Repo, migration_source: "my_migrations"
* `:migration_lock` - By default, Ecto will lock the migration source to throttle
multiple nodes to run migrations one at a time. You can disable the `migration_lock`
by setting it to `false`. You may also select a different locking strategy if
supported by the adapter. See the adapter docs for more information.
config :app, App.Repo, migration_lock: false
# Or use a different locking strategy. For example, Postgres can use advisory
# locks but be aware that your database configuration might not make this a good
# fit. See the Ecto.Adapters.Postgres for more information:
config :app, App.Repo, migration_lock: :pg_advisory_lock
* `:migration_repo` - The migration repository is where the table managing the
migrations will be stored (`migration_source` defines the table name). It defaults
to the given repository itself but you can configure it via:
config :app, App.Repo, migration_repo: App.MigrationRepo
* `:priv` - the priv directory for the repo with the location of important assets,
such as migrations. For a repository named `MyApp.FooRepo`, `:priv` defaults to
"priv/foo_repo" and migrations should be placed at "priv/foo_repo/migrations"
* `:start_apps_before_migration` - A list of applications to be started before
running migrations. Used by `Ecto.Migrator.with_repo/3` and the migration tasks:
config :app, App.Repo, start_apps_before_migration: [:ssl, :some_custom_logger]
### Migrations configuration
These options configure how each migration works. **It is generally discouraged
to change any of those configurations after your database is deployed to production,
as changing these options will retroactively change how all migrations work**.
* `:migration_primary_key` - By default, Ecto uses the `:id` column with type
`:bigserial`, but you can configure it via:
config :app, App.Repo, migration_primary_key: [name: :uuid, type: :binary_id]
config :app, App.Repo, migration_primary_key: false
* `:migration_foreign_key` - By default, Ecto uses the `primary_key` type
for foreign keys when `references/2` is used, but you can configure it via:
config :app, App.Repo, migration_foreign_key: [column: :uuid, type: :binary_id]
* `:migration_timestamps` - By default, Ecto uses the `:naive_datetime` as the type,
`:inserted_at` as the name of the column for storing insertion times, `:updated_at` as
the name of the column for storing last-updated-at times, but you can configure it
via:
config :app, App.Repo, migration_timestamps: [
type: :utc_datetime,
inserted_at: :created_at,
updated_at: :changed_at
]
* `:migration_default_prefix` - Ecto defaults to `nil` for the database prefix for
migrations, but you can configure it via:
config :app, App.Repo, migration_default_prefix: "my_prefix"
## Comments
Migrations where you create or alter a table support specifying table
and column comments. The same can be done when creating constraints
and indexes. Not all databases support this feature.
def up do
create index("posts", [:name], comment: "Index Comment")
create constraint("products", "price_must_be_positive", check: "price > 0", comment: "Constraint Comment")
create table("weather", prefix: "north_america", comment: "Table Comment") do
add :city, :string, size: 40, comment: "Column Comment"
timestamps()
end
end
## Prefixes
Migrations support specifying a table prefix or index prefix which will
target either a schema (if using PostgreSQL) or a different database (if using
MySQL). If no prefix is provided, the default schema or database is used.
Any reference declared in the table migration refers by default to the table
with the same declared prefix. The prefix is specified in the table options:
def up do
create table("weather", prefix: "north_america") do
add :city, :string, size: 40
add :temp_lo, :integer
add :temp_hi, :integer
add :prcp, :float
add :group_id, references(:groups)
timestamps()
end
create index("weather", [:city], prefix: "north_america")
end
Note: if using MySQL with a prefixed table, you must use the same prefix
for the references since cross-database references are not supported.
When using a prefixed table with either MySQL or PostgreSQL, you must use the
same prefix for the index field to ensure that you index the prefix-qualified
table.
## Transaction Callbacks
If possible, each migration runs inside a transaction. This is true for Postgres,
but not true for MySQL, as the latter does not support DDL transactions.
In some rare cases, you may need to execute some common behavior after beginning
a migration transaction, or before committing that transaction. For instance, one
might desire to set a `lock_timeout` for each lock in the migration transaction.
You can do so by defining `c:after_begin/0` and `c:before_commit/0` callbacks to
your migration.
However, if you need do so for every migration module, implement this callback
for every migration can be quite repetitive. Luckily, you can handle this by
providing your migration module:
defmodule MyApp.Migration do
defmacro __using__(_) do
quote do
use Ecto.Migration
def after_begin() do
repo().query! "SET lock_timeout TO '5s'"
end
end
end
end
Then in your migrations you can `use MyApp.Migration` to share this behavior
among all your migrations.
## Additional resources
* The [Safe Ecto Migrations guide](https://fly.io/phoenix-files/safe-ecto-migrations/)
"""
@doc """
Migration code to run immediately after the transaction is opened.
Keep in mind that it is treated like any normal migration code, and should
consider both the up *and* down cases of the migration.
"""
@callback after_begin() :: term
@doc """
Migration code to run immediately before the transaction is closed.
Keep in mind that it is treated like any normal migration code, and should
consider both the up *and* down cases of the migration.
"""
@callback before_commit() :: term
@optional_callbacks after_begin: 0, before_commit: 0
defmodule Index do
@moduledoc """
Used internally by adapters.
To define an index in a migration, see `Ecto.Migration.index/3`.
"""
defstruct table: nil,
prefix: nil,
name: nil,
columns: [],
unique: false,
concurrently: false,
using: nil,
include: [],
only: false,
nulls_distinct: nil,
where: nil,
comment: nil,
options: nil
@type t :: %__MODULE__{
table: String.t,
prefix: atom,
name: atom,
columns: [atom | String.t],
unique: boolean,
concurrently: boolean,
using: atom | String.t,
only: boolean,
include: [atom | String.t],
nulls_distinct: boolean | nil,
where: atom | String.t,
comment: String.t | nil,
options: String.t
}
end
defmodule Table do
@moduledoc """
Used internally by adapters.
To define a table in a migration, see `Ecto.Migration.table/2`.
"""
defstruct name: nil, prefix: nil, comment: nil, primary_key: true, engine: nil, options: nil
@type t :: %__MODULE__{name: String.t, prefix: atom | nil, comment: String.t | nil, primary_key: boolean | keyword(),
engine: atom, options: String.t}
end
defmodule Reference do
@moduledoc """
Used internally by adapters.
To define a reference in a migration, see `Ecto.Migration.references/2`.
"""
defstruct name: nil, prefix: nil, table: nil, column: :id, type: :bigserial,
on_delete: :nothing, on_update: :nothing, validate: true,
with: [], match: nil
@type t :: %__MODULE__{table: String.t, prefix: atom | nil, column: atom, type: atom,
on_delete: atom, on_update: atom, validate: boolean,
with: list, match: atom | nil}
end
defmodule Constraint do
@moduledoc """
Used internally by adapters.
To define a constraint in a migration, see `Ecto.Migration.constraint/3`.
"""
defstruct name: nil, table: nil, check: nil, exclude: nil, prefix: nil, comment: nil, validate: true
@type t :: %__MODULE__{name: atom, table: String.t, prefix: atom | nil,
check: String.t | nil, exclude: String.t | nil, comment: String.t | nil, validate: boolean}
end
defmodule Command do
@moduledoc """
Used internally by adapters.
This represents the up and down legs of a reversible raw command
that is usually defined with `Ecto.Migration.execute/1`.
To define a reversible command in a migration, see `Ecto.Migration.execute/2`.
"""
defstruct up: nil, down: nil
@type t :: %__MODULE__{up: String.t, down: String.t}
end
alias Ecto.Migration.Runner
@doc false
defmacro __using__(_) do
quote location: :keep do
import Ecto.Migration
@disable_ddl_transaction false
@disable_migration_lock false
@before_compile Ecto.Migration
end
end
@doc false
defmacro __before_compile__(_env) do
quote do
def __migration__ do
[
disable_ddl_transaction: @disable_ddl_transaction,
disable_migration_lock: @disable_migration_lock
]
end
end
end
@doc """
Creates a table.
By default, the table will also include an `:id` primary key field that
has a type of `:bigserial`. Check the `table/2` docs for more information.
## Examples
create table(:posts) do
add :title, :string, default: "Untitled"
add :body, :text
timestamps()
end
"""
defmacro create(object, do: block) do
expand_create(object, :create, block)
end
@doc """
Creates a table if it does not exist.
Works just like `create/2` but does not raise an error when the table
already exists.
"""
defmacro create_if_not_exists(object, do: block) do
expand_create(object, :create_if_not_exists, block)
end
defp expand_create(object, command, block) do
quote do
table = %Table{} = unquote(object)
Runner.start_command({unquote(command), Ecto.Migration.__prefix__(table)})
if primary_key = Ecto.Migration.__primary_key__(table) do
{name, type, opts} = primary_key
add(name, type, opts)
end
unquote(block)
Runner.end_command()
table
end
end
@doc """
Alters a table.
## Examples
alter table("posts") do
add :summary, :text
modify :title, :text
remove :views
end
"""
defmacro alter(object, do: block) do
quote do
table = %Table{} = unquote(object)
Runner.start_command({:alter, Ecto.Migration.__prefix__(table)})
unquote(block)
Runner.end_command()
end
end
@doc """
Creates one of the following:
* an index
* a table with only the :id primary key
* a constraint
When reversing (in a `change/0` running backwards), indexes are only dropped
if they exist, and no errors are raised. To enforce dropping an index, use
`drop/1`.
## Examples
create index("posts", [:name])
create table("version")
create constraint("products", "price_must_be_positive", check: "price > 0")
"""
def create(%Index{} = index) do
Runner.execute {:create, __prefix__(index)}
index
end
def create(%Constraint{} = constraint) do
Runner.execute {:create, __prefix__(constraint)}
constraint
end
def create(%Table{} = table) do
do_create table, :create
table
end
@doc """
Creates an index or a table with only `:id` field if one does not yet exist.
## Examples
create_if_not_exists index("posts", [:name])
create_if_not_exists table("version")
"""
def create_if_not_exists(%Index{} = index) do
Runner.execute {:create_if_not_exists, __prefix__(index)}
end
def create_if_not_exists(%Table{} = table) do
do_create table, :create_if_not_exists
end
defp do_create(table, command) do
columns =
if primary_key = Ecto.Migration.__primary_key__(table) do
{name, type, opts} = primary_key
[{:add, name, type, opts}]
else
[]
end
Runner.execute {command, __prefix__(table), columns}
end
@doc """
Drops one of the following:
* an index
* a table
* a constraint
## Examples
drop index("posts", [:name])
drop table("posts")
drop constraint("products", "price_must_be_positive")
drop index("posts", [:name]), mode: :cascade
drop table("posts"), mode: :cascade
## Options
* `:mode` - when set to `:cascade`, automatically drop objects that depend
on the index, and in turn all objects that depend on those objects
on the table. Default is `:restrict`
"""
def drop(%{} = index_or_table_or_constraint, opts \\ []) when is_list(opts) do
Runner.execute {:drop, __prefix__(index_or_table_or_constraint), Keyword.get(opts, :mode, :restrict)}
index_or_table_or_constraint
end
@doc """
Drops a table or index if it exists.
Does not raise an error if the specified table or index does not exist.
## Examples
drop_if_exists index("posts", [:name])
drop_if_exists table("posts")
drop_if_exists index("posts", [:name]), mode: :cascade
drop_if_exists table("posts"), mode: :cascade
## Options
* `:mode` - when set to `:cascade`, automatically drop objects that depend
on the index, and in turn all objects that depend on those objects
on the table. Default is `:restrict`
"""
def drop_if_exists(%{} = index_or_table, opts \\ []) when is_list(opts) do
Runner.execute {:drop_if_exists, __prefix__(index_or_table), Keyword.get(opts, :mode, :restrict)}
index_or_table
end
@doc """
Returns a table struct that can be given to `create/2`, `alter/2`, `drop/1`,
etc.
## Examples
create table("products") do
add :name, :string
add :price, :decimal
end
drop table("products")
create table("products", primary_key: false) do
add :name, :string
add :price, :decimal
end
create table("daily_prices", primary_key: false, options: "PARTITION BY RANGE (date)") do
add :name, :string, primary_key: true
add :date, :date, primary_key: true
add :price, :decimal
end
## Options
* `:primary_key` - when `false`, a primary key field is not generated on table
creation. Alternatively, a keyword list in the same style of the
`:migration_primary_key` repository configuration can be supplied
to control the generation of the primary key field. The keyword list
must include `:name` and `:type`. See `add/3` for further options.
* `:engine` - customizes the table storage for supported databases. For MySQL,
the default is InnoDB.
* `:prefix` - the prefix for the table. This prefix will automatically be used
for all constraints and references defined for this table unless explicitly
overridden in said constraints/references.
* `:comment` - adds a comment to the table.
* `:options` - provide custom options that will be appended after the generated
statement. For example, "WITH", "INHERITS", or "ON COMMIT" clauses. "PARTITION BY"
can be provided for databases that support table partitioning.
"""
def table(name, opts \\ [])
def table(name, opts) when is_atom(name) do
table(Atom.to_string(name), opts)
end
def table(name, opts) when is_binary(name) and is_list(opts) do
struct(%Table{name: name}, opts)
end
@doc ~S"""
Returns an index struct that can be given to `create/1`, `drop/1`, etc.
Expects the table name as the first argument and the index field(s) as
the second. The fields can be atoms, representing columns, or strings,
representing expressions that are sent as-is to the database.
## Options
* `:name` - the name of the index. Defaults to "#{table}_#{column}_index".
* `:unique` - indicates whether the index should be unique. Defaults to
`false`.
* `:concurrently` - indicates whether the index should be created/dropped
concurrently.
* `:using` - configures the index type.
* `:prefix` - specify an optional prefix for the index.
* `:where` - specify conditions for a partial index.
* `:include` - specify fields for a covering index. This is not supported
by all databases. For more information on PostgreSQL support, please
[read the official docs](https://www.postgresql.org/docs/current/indexes-index-only-scans.html).
* `:nulls_distinct` - specify whether null values should be considered
distinct for a unique index. Defaults to `nil`, which will not add the
parameter to the generated SQL and thus use the database default.
This option is currently only supported by PostgreSQL 15+.
For MySQL, it is always false. For MSSQL, it is always true.
See the dedicated section on this option for more information.
* `:only` - Indicates not to recurse creating indexes on partitions, if the table is partitioned.
This option is currently only supported by PostgreSQL 11+. Defaults to `false`.
* `:comment` - adds a comment to the index.
## Adding/dropping indexes concurrently
PostgreSQL supports adding/dropping indexes concurrently (see the
[docs](http://www.postgresql.org/docs/current/static/sql-createindex.html)).
However, this feature does not work well with the transactions used by
Ecto to guarantee integrity during migrations.
You can address this with two changes:
1. Change your repository to use PG advisory locks as the migration lock.
Note this may not be supported by Postgres-like databases and proxies.
2. Disable DDL transactions. Doing this removes the guarantee that all of
the changes in the migration will happen at once, so you will want to
keep it short.
If the database adapter supports several migration lock strategies, such as
Postgrex, then review those strategies and consider using a strategy that
utilizes advisory locks to faciliate running migrations one at a time even
across multiple nodes. For example:
# Config the Repo (PostgreSQL example)
config MyApp.Repo, migration_lock: :pg_advisory_lock
# Migrate with your concurrent operation
defmodule MyRepo.Migrations.CreateIndexes do
use Ecto.Migration
@disable_ddl_transaction true
def change do
create index("posts", [:slug], concurrently: true)
end
end
## Index types
When creating an index, the index type can be specified with the `:using`
option. The `:using` option can be an atom or a string, and its value is
passed to the generated `USING` clause as-is.
For example, PostgreSQL supports several index types like B-tree (the
default), Hash, GIN, and GiST. More information on index types can be found
in the [PostgreSQL docs](http://www.postgresql.org/docs/current/indexes-types.html).
## Partial indexes
Databases like PostgreSQL and MSSQL support partial indexes.
A partial index is an index built over a subset of a table. The subset
is defined by a conditional expression using the `:where` option.
The `:where` option can be an atom or a string; its value is passed
to the generated `WHERE` clause as-is.
More information on partial indexes can be found in the [PostgreSQL
docs](http://www.postgresql.org/docs/current/indexes-partial.html).
## The `:nulls_distinct` option
A unique index does not prevent multiple null values by default in most databases.
For example, imagine we have a "products" table and need to guarantee that
sku's are unique within their category, but the category is optional.
Creating a regular unique index over the sku and category_id fields with:
create index("products", [:sku, :category_id], unique: true)
will allow products with the same sku to be inserted if their category_id is `nil`.
The `:nulls_distinct` option can be used to change this behavior by considering
null values as equal, i.e. not distinct:
create index("products", [:sku, :category_id], unique: true, nulls_distinct: false)
This option is currently only supported by PostgreSQL 15+.
As a workaround for older PostgreSQL versions and other databases, an
additional partial unique index for the sku can be created:
create index("products", [:sku, :category_id], unique: true)
create index("products", [:sku], unique: true, where: "category_id IS NULL")
## Examples
# With no name provided, the name of the below index defaults to
# products_category_id_sku_index
create index("products", [:category_id, :sku], unique: true)
# The name can also be set explicitly
create index("products", [:category_id, :sku], name: :my_special_name)
# Indexes can be added concurrently
create index("products", [:category_id, :sku], concurrently: true)
# The index type can be specified
create index("products", [:name], using: :hash)
# Partial indexes are created by specifying a :where option
create index("products", [:user_id], where: "price = 0", name: :free_products_index)
# Covering indexes are created by specifying a :include option
create index("products", [:user_id], include: [:category_id])
Indexes also support custom expressions. Some databases may require the
index expression to be written between parentheses:
# Create an index on a custom expression
create index("products", ["(lower(name))"], name: :products_lower_name_index)
# Create a tsvector GIN index on PostgreSQL
create index("products", ["(to_tsvector('english', name))"],
name: :products_name_vector, using: "GIN")
"""
def index(table, columns, opts \\ [])
def index(table, columns, opts) when is_atom(table) do
index(Atom.to_string(table), columns, opts)
end
def index(table, column, opts) when is_binary(table) and is_atom(column) do
index(table, [column], opts)
end
def index(table, columns, opts) when is_binary(table) and is_list(columns) and is_list(opts) do
validate_index_opts!(opts)
index = struct(%Index{table: table, columns: columns}, opts)
%{index | name: index.name || default_index_name(index)}
end
@doc """
Shortcut for creating a unique index.
See `index/3` for more information.
"""
def unique_index(table, columns, opts \\ [])
def unique_index(table, columns, opts) when is_list(opts) do
index(table, columns, [unique: true] ++ opts)
end
defp default_index_name(index) do
[index.table, index.columns, "index"]
|> List.flatten
|> Enum.map(&to_string(&1))
|> Enum.map(&String.replace(&1, ~r"[^\w_]", "_"))
|> Enum.map(&String.replace_trailing(&1, "_", ""))
|> Enum.join("_")
|> String.to_atom
end
@doc """
Executes arbitrary SQL, anonymous function or a keyword command.
The argument is typically a string, containing the SQL command to be executed.
Keyword commands exist for non-SQL adapters and are not used in most situations.
Supplying an anonymous function does allow for arbitrary code to execute as
part of the migration. This is most often used in combination with `repo/0`
by library authors who want to create high-level migration helpers.
Reversible commands can be defined by calling `execute/2`.
## Examples
execute "CREATE EXTENSION postgres_fdw"
execute create: "posts", capped: true, size: 1024
execute(fn -> repo().query!("SELECT $1::integer + $2", [40, 2], [log: :info]) end)
execute(fn -> repo().update_all("posts", set: [published: true]) end)
"""
def execute(command) when is_binary(command) or is_function(command, 0) or is_list(command) do
Runner.execute command
end
@doc """
Executes reversible SQL commands.
This is useful for database-specific functionality that does not
warrant special support in Ecto, for example, creating and dropping
a PostgreSQL extension. The `execute/2` form avoids having to define
separate `up/0` and `down/0` blocks that each contain an `execute/1`
expression.
The allowed parameters are explained in `execute/1`.
## Examples
defmodule MyApp.MyMigration do
use Ecto.Migration
def change do
execute "CREATE EXTENSION postgres_fdw", "DROP EXTENSION postgres_fdw"
execute(&execute_up/0, &execute_down/0)
end
defp execute_up, do: repo().query!("select 'Up query …';", [], [log: :info])
defp execute_down, do: repo().query!("select 'Down query …';", [], [log: :info])
end
"""
def execute(up, down) when (is_binary(up) or is_function(up, 0) or is_list(up)) and
(is_binary(down) or is_function(down, 0) or is_list(down)) do
Runner.execute %Command{up: up, down: down}
end
@doc """
Executes a SQL command from a file.
The argument must be a path to a file containing a SQL command.
Reversible commands can be defined by calling `execute_file/2`.
"""
def execute_file(path) when is_binary(path) do
command = File.read!(path)
Runner.execute command
end
@doc """
Executes reversible SQL commands from files.
Each argument must be a path to a file containing a SQL command.
See `execute/2` for more information on executing SQL commands.
"""
def execute_file(up_path, down_path) when is_binary(up_path) and is_binary(down_path) do
up = File.read!(up_path)
down = File.read!(down_path)
Runner.execute %Command{up: up, down: down}
end
@doc """
Gets the migrator direction.
"""
@spec direction :: :up | :down
def direction do
Runner.migrator_direction()
end
@doc """
Gets the migrator repo.
"""
@spec repo :: Ecto.Repo.t
def repo do
Runner.repo()
end
@doc """
Gets the migrator prefix.
"""
def prefix do
Runner.prefix()
end
@doc """
Adds a column when creating or altering a table.
This function also accepts Ecto primitive types as column types
that are normalized by the database adapter. For example,
`:string` is converted to `:varchar`, `:binary` to `:bits` or `:blob`,
and so on.
However, the column type is not always the same as the type used in your
schema. For example, a schema that has a `:string` field can be supported by
columns of type `:char`, `:varchar`, `:text`, and others. For this reason,
this function also accepts `:text` and other type annotations that are native
to the database. These are passed to the database as-is.
To sum up, the column type may be either an Ecto primitive type,
which is normalized in cases where the database does not understand it,
such as `:string` or `:binary`, or a database type which is passed as-is.
Custom Ecto types like `Ecto.UUID` are not supported because
they are application-level concerns and may not always map to the database.
Note: It may be necessary to quote case-sensitive, user-defined type names.