You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@devlake.apache.org by yu...@apache.org on 2022/08/26 06:35:03 UTC

[incubator-devlake-website] 02/06: DB migrations extra docs added

This is an automated email from the ASF dual-hosted git repository.

yumeng pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/incubator-devlake-website.git

commit d93a40f38eb5891908e36a004891585bdfb6a771
Author: Keon Amini <ke...@skael.com>
AuthorDate: Thu Aug 25 18:45:47 2022 -0500

    DB migrations extra docs added
---
 docs/DeveloperManuals/DBMigration.md | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/docs/DeveloperManuals/DBMigration.md b/docs/DeveloperManuals/DBMigration.md
index 95302379..53160498 100644
--- a/docs/DeveloperManuals/DBMigration.md
+++ b/docs/DeveloperManuals/DBMigration.md
@@ -18,17 +18,33 @@ When DevLake starts, scripts register themselves to the framework by invoking th
 
 ```go
 type Script interface {
+    // this function will contain the business logic of the migration (e.g. DDL logic)
 	Up(ctx context.Context, db *gorm.DB) error
+    // the version number of the migration. typically in date format (YYYYMMDDHHMMSS), e.g. 20220728000001. Migrations are executed sequentially based on this number.
 	Version() uint64
+	// The name of this migration
 	Name() string
 }
 ```
 
+## Migration Model
+
+For each migration we define a "snapshot" datamodel of the model that we wish to perform the migration on.
+The fields on this model shall be identical to the actual model, but unlike the actual one, this one will
+never change in the future. The naming convention of these models is `<ModelName>YYYYMMDD` and they must implement
+the `func TableName() string` method, and consumed by the `Script::Up` method.
+
 ## Table `migration_history`
 
 The table tracks migration scripts execution and schemas changes.
 From which, DevLake could figure out the current state of database schemas.
 
+## Execution
+
+Each plugin has a `migrationscripts` subpackage that lists all the migrations to be executed for that plugin. You
+will need to add your migration to that list for the framework to pick it up. Similarly, there is such a package
+for the framework-only migrations defined under the `models` package.
+
 
 ## How It Works
 1. Check `migration_history` table, calculate all the migration scripts need to be executed.