Migrations

[michalmuskala]

As discussed with @josevalim we could support some migrations, especially for adding and removing indexes.

[michalmuskala]

I tried integrating the migrator tests, and it seems for me to be quite complicated.
I managed to change the Ecto.Migration.SchemaMigration model not to have a primary key (in definition), and I had to change MockRepo because of that - michalmuskala/ecto@a0c6364

Unfortunately this wasn't that helpfull as nearly all migrator tests rely on the fact that each test runs in transaction. I can either truncate the schema_migrations table after each test together with everything else or I can keep it, but that poses other issues, as the table is not cleaned between tests.

@josevalim @ericmj thoughts?

[josevalim]

You need to set support_ddl_transactions? to false so it doesn't run them inside a transaction.

[michalmuskala]

That is not the problem. The problem is with tests themselves. Each of them assumes it starts at a certain point - with only one record in schema_migrations table that is inserted there when the test migrations are run with:

:ok = Ecto.Migrator.up(TestRepo, 0, Ecto.Integration.Migration, log: false)

in the test_helper.exs.

I changed the tests accordingly, but I'm not sure that's the way to go:
michalmuskala/ecto@fcec725

[josevalim]

Maybe it is easier to run a dummy migration in the test helper too?

On Friday, July 3, 2015, Michał Muskała [email protected] wrote:

That is not the problem. The problem is with tests themselves. Each of
them assumes it starts at a certain point - with only one record in
schema_migrations table that is inserted there when the test migrations
are run with:

:ok = Ecto.Migrator.up(TestRepo, 0, Ecto.Integration.Migration, log: false)

in the test_helper.exs.

I changed the tests accordingly, but I'm not sure that's the way to go:
michalmuskala/ecto@fcec725
michalmuskala/ecto@fcec725

—
Reply to this email directly or view it on GitHub
#12 (comment)
.

José Valimwww.plataformatec.com.br
http://www.plataformatec.com.br/Founder and Director of R&D

[michalmuskala]

This commit adds support for migrations 5d654b3

It's on a branch, because it's using my fork of ecto with the changes I mentioned earlier.

I'm running the migrations provided with integration suite (as I need to support table ddl anyway for schema_migrations table) - just ignoring any body for create_table/2. But that still won't solve the problem. I think I did bad job at explaining what it is.

There are two ways to handle schema_migrations collection:

• drop it with truncate as every other table - in that case we need a setup call that will reinsert the 0th migration
• keep it between the tests - in that case there might be something besides that 0th migration once we reach the test (as other tests might have inserted it). That's what I'm doing right now.

To handle the schema_migrations collection not beeing dropped between the tests, we could:

• make each test clean-up after itself
• make the tests not rely on the fact that there is only the 0th migration when it starts. That's what I'm doing right now.

Is there some other way, or is the other way I mentioned better?