feat: database migrations #33
Conversation
- renamed 'version' to 'id' in migrations - change from integer to timestamp string in the format of 'yyyy_MM_dd_HHmmss'
tunder/lib/src/console/commands/migrations/make_migration_command.dart
Outdated
Show resolved
Hide resolved
tunder/lib/src/console/commands/migrations/migrate_rollback_command.dart
Show resolved
Hide resolved
- refactor(database): refactor database operations individually as contracts to a single class implementing a contract for the database driver. This makes new implementations for new drivers easier in the future.
It wipes all database tables and re-run all migrations. - refactor: all migration commands to "migrations" category - chore: add more tests to migration commands to test command name, description and category.
| Future<int> dropAllTables(); | ||
| Future<int> update(Query query, MappedRow row); | ||
| Future<List<MappedRow>> process(Query query); | ||
| String toSql(Query query); |
There was a problem hiding this comment.
@Wdestroier I followed your suggestion about refactoring the database operations to put them all in a class that makes it easier to implement for other drivers and here you are. Now, we just need to implement two classes DatabaseOperator and SchemaProcessor to implement a new database driver. In the future, I will also refactor the SchemaProcessor to use the database operator instead. This will make it, even more, easier to implement in the future. Please let me know if you have any other thoughts or suggestions.
Now I just implemented the PostgresDatabaseOperator to follow the database operator contract (interface). The postgres directory contains everything related to the Postgres driver implementation. It's a good pattern but we don't necessarily need to follow it, but I think it's a good way to implement this contract.
Available commands: