luckyframework / luckyframework/avram
[Improvement] Better usage when use `make_required` `make_optional` and `remove` on the migration.
Nobody has claimed this yet.
- 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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