Entity-independent migrations

[kpot]

Hi,

I'm just l learning SeaQL ecosystem, and, if I read the docs correctly, in all migrations I have to use the original Entity in order to describe how to create/modify the tables, like so

Table::create()
    .table(Entity)
    .if_not_exists()
    .col(
        ColumnDef::new(Column::Id)
            .integer()
            .not_null()
            .auto_increment()
            .primary_key(),
    )
    .col(ColumnDef::new(Column::Title).string().not_null())
    ...

All these Column::Title and Column::Id bother me a lot.
Aren't the migrations supposed to be completely independent from the "current state" of the Entity? In theory, my migrations should be able to run back and forth every transformation even if all entities/columns were refactored multiple times.
In Django all migrations are completely independent and self-contained, and thus always work if done right.

Is there a proper way to write self-contained migrations with Sea-Schema?

[kpot]

After some digging inside the SeaSchema`s code I found a solution that does the job, although it's a bit verbose. I wonder if something like this should be added to the docs.

Table::create()
    .table(TableRef::Table(Alias::new("my_table_name").into_iden()))
    .if_not_exists()
    .col(
        ColumnDef::new(Alias::new("id"))
            .integer()
            .not_null()
            .auto_increment()
            .primary_key(),
    )
    .col(ColumnDef::new(Alias::new("title")).string().not_null())
    ...

The TableRef enum also offers a variety of other options to specify the table.

Respect to all authors for a great project! You're totally going in the right direction.

[tyt2y3]

Thank you for the input.

Actually you can take a look into the https://github.com/SeaQL/sea-orm/tree/master/examples
Interestingly (or confusingly) the examples have slightly different migration strategies.
Basically, you can either:

1. write SQL
2. build TableCreateStatement from sea-query (schema first)
3. embed a snapshot of your entity in the migration crate (entity first)

[tyt2y3]

Developers have different expectations on this messy matters and I can only say every approach is fine but you need to have that thought out.
If you have the time and energy, I'd appreciate if you can open a PR on our docs to help clarify things