luckyframework / luckyframework/avram

[Improvement] Better usage when use `make_required` `make_optional` and `remove` on the migration.

Open
#1,033 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

clarify api
Dominant language
Crystal
Stars
183
Forks
67
PR merge metrics
No merged PRs in 30d

Description

Assume my db table foo, have two column, column1, column2

this is a common use case where the data from `column1` is migrated to `column2` and then remove column `column1`, and then make column2 required.

so, migration like this:

```cr
class Foo::V20240427102500 < Avram::Migrator::Migration::V1
def migrate
# Do data migrating from column1 to column2 ...

make_required table_for(Foo), :column2
alter table_for(Foo) do
remove :column1
end
end

def rollback
end
end
```

It works!, but i consider it is better if we can use like following:

```cr
alert table_for(Foo) do
make_required :column2
remove :column1
end
```
Or

```cr
make_required table_for(Foo), :column2
remove table_for(Foo), :column1
```

Thanks

----------------

EDIT: okay, probably write `migrate data` and `delete old column` in same migration file is not good idea, but anyway, same usage is better.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the migration DSL entry points for make_required, make_optional, remove, alter, and table_for, comparing the existing call forms with the requested block and table-first forms. Done means the requested migration syntax works while the existing syntax remains usable, with coverage for the shown column changes.

Written by the indexing model from the issue text.

Assessment

Tech stack
crystal, postgresql
Domain
database
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.