luckyframework / luckyframework/avram
Some incorrect migration useage that works but shouldn't
- Dominant language
- Crystal
- Stars
- 183
- Forks
- 67
- PR merge metrics
- No merged PRs in 30d
Description
I'm going through my migrations, and seeing all kinds of "issues" that I would expect to not work, but they seem to be working fine... It leads to lots of inconsistencies though, so I'll list them out here, and we can work out fixing them.
* [ ] - Using a plural model name with `table_for`. (e.g. `table_for(Users)`)
* [ ] - Using `make_required` or `make_optional` inside of a `alter` block. These will create nested `ALTER TABLE` statements that postgres seems to ignore... but it should be a compile-error, or maybe we change how they work?
* [ ] - Using both `default` and `fill_existing_with`... We actually already have an error for this https://github.com/luckyframework/avram/blob/a3d830cac03f035a299e9c8fa6d099e43348b11b/src/avram/migrator/alter_table_statement.cr#L144 but I have code doing this, and it's not failing...
* [ ] - `rollback` not reversing `migrate`... This might just be a "wish", but I think it would be more "Lucky-ish" if the `rollback` had to be filled in with either some sort of `irreversable_migration_error` method or by reversing the migrate.. Rails kind of does this automagically
Contributor guide
Research direction
Start by reviewing the migration behavior described for table_for, alter blocks, default/fill_existing_with, and rollback/migrate. Check src/avram/migrator/alter_table_statement.cr around line 144, where an existing error is mentioned. Done means the listed invalid or inconsistent migration cases have clearly defined and consistently enforced behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- crystal, postgresql
- Domain
- database
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100