|
|
@@ -158,10 +158,21 @@ When you need to make schema changes:
|
|
|
|
|
|
4. Commit both the migration file and any code changes that depend on the new schema.
|
|
|
|
|
|
-### Migration Best Practices
|
|
|
+## Database Development Workflow
|
|
|
|
|
|
-- Never modify existing migration files after they've been committed.
|
|
|
-- If you need to change a migration, create a new one that undoes and redoes the changes.
|
|
|
-- Test migrations on a copy of production data before applying to production.
|
|
|
-- Keep migrations small and focused on a single change.
|
|
|
-- Use descriptive names for migration files.
|
|
|
+Since `database.db` is tracked in git to ensure schema consistency, follow this workflow for database changes:
|
|
|
+
|
|
|
+1. **Schema Changes**: Create migrations for any schema modifications
|
|
|
+2. **Data Changes**: If you need to modify data during development, do it through code or migrations
|
|
|
+3. **Testing**: Use `database-test.db` for testing to avoid committing test data
|
|
|
+4. **Production**: Never commit data changes to `database.db` - only schema changes via migrations
|
|
|
+
|
|
|
+### Handling Database Changes
|
|
|
+
|
|
|
+If you accidentally modify `database.db` with data changes:
|
|
|
+
|
|
|
+1. Revert the file: `git restore data/database.db`
|
|
|
+2. If schema changes are needed, create a migration
|
|
|
+3. If data changes are needed, implement them in application code
|
|
|
+
|
|
|
+This ensures the git commit flow remains clean and migrations can bring any database to the correct state.
|