graphql-engine/cli/migrate/cmd/commands.go

260 lines
4.9 KiB
Go
Raw Normal View History

2018-06-24 16:40:48 +03:00
package cmd
import (
"encoding/json"
"fmt"
"io/ioutil"
"os"
"path/filepath"
"runtime"
cli(migrations): new folder structure and squash (#3072) ### Description This PR introduces three new features: - Support for a new migrations folder structure. - Add `squash` command in preview. - ~List of migrations on the Console and ability to squash them from console.~ #### New migrations folder structure Starting with this commit, Hasura CLI supports a new directory structure for migrations folder and defaults to that for all new migrations created. Each migration will get a new directory with the name format `timestamp_name` and inside the directory, there will be four files: ```bash └── migrations ├── 1572237730898_squashed │ ├── up.sql │ ├── up.yaml │ ├── down.yaml │ └── down.sql ``` Existing files old migration format `timestamp_name.up|down.yaml|sql` will continue to work alongside new migration files. #### Squash command Lots of users have expressed their interest in squashing migrations (see #2724 and #2254) and some even built [their own tools](https://github.com/domasx2/hasura-squasher) to do squash. In this PR, we take a systematic approach to squash migrations. A new command called `migrate squash` is introduced. Note that this command is in **PREVIEW** and the correctness of squashed migration is not guaranteed (especially for down migrations). From our tests, **it works for most use cases**, but we have found some issues with squashing all the down migrations, partly because the console doesn't generate down migrations for all actions. Hence, until we add an extensive test suite for squashing, we'll keep the command in preview. We recommend you to confirm the correctness yourself by diffing the SQL and Metadata before and after applying the squashed migrations (we're also thinking about embedding some checks into the command itself). ```bash $ hasura migrate squash --help (PREVIEW) Squash multiple migrations leading upto the latest one into a single migration file Usage: hasura migrate squash [flags] Examples: # NOTE: This command is in PREVIEW, correctness is not guaranteed and the usage may change. # squash all migrations from version 1572238297262 to the latest one: hasura migrate squash --from 1572238297262 Flags: --from uint start squashing form this version --name string name for the new squashed migration (default "squashed") --delete-source delete the source files after squashing without any confirmation ``` ### Affected components <!-- Remove non-affected components from the list --> - CLI ### Related Issues <!-- Please make sure you have an issue associated with this Pull Request --> <!-- And then add `(close #<issue-no>)` to the pull request title --> <!-- Add the issue number below (e.g. #234) --> Close #2724, Close #2254, ### Solution and Design <!-- How is this issue solved/fixed? What is the design? --> <!-- It's better if we elaborate --> For the squash command, a state machine is implemented to track changes to Hasura metadata. After applying each action on the metadata state, a list of incremental changes is created. ### Steps to test and verify 1. Open console via cli and create some migrations. 2. Run `hasura migrate squash --from <version>` ### Limitations, known bugs & workarounds <!-- Limitations of the PR, known bugs and suggested workarounds --> <!-- Feel free to delete these comment lines --> - The `squash` command is in preview - Support for squashing from the console is WIP - Support for squashing migrations that are not committed yet is planned. - Un-tracking or dropping a table will cause inconsistent squashed down migration since console doesn't generate correct down migration. - If cascade setting is set to `true` on any of the metadata action, generated migration may be wrong
2019-10-31 05:21:15 +03:00
"strconv"
2018-06-24 16:40:48 +03:00
"strings"
"github.com/ghodss/yaml"
"github.com/hasura/graphql-engine/cli/migrate"
cli(migrations): new folder structure and squash (#3072) ### Description This PR introduces three new features: - Support for a new migrations folder structure. - Add `squash` command in preview. - ~List of migrations on the Console and ability to squash them from console.~ #### New migrations folder structure Starting with this commit, Hasura CLI supports a new directory structure for migrations folder and defaults to that for all new migrations created. Each migration will get a new directory with the name format `timestamp_name` and inside the directory, there will be four files: ```bash └── migrations ├── 1572237730898_squashed │ ├── up.sql │ ├── up.yaml │ ├── down.yaml │ └── down.sql ``` Existing files old migration format `timestamp_name.up|down.yaml|sql` will continue to work alongside new migration files. #### Squash command Lots of users have expressed their interest in squashing migrations (see #2724 and #2254) and some even built [their own tools](https://github.com/domasx2/hasura-squasher) to do squash. In this PR, we take a systematic approach to squash migrations. A new command called `migrate squash` is introduced. Note that this command is in **PREVIEW** and the correctness of squashed migration is not guaranteed (especially for down migrations). From our tests, **it works for most use cases**, but we have found some issues with squashing all the down migrations, partly because the console doesn't generate down migrations for all actions. Hence, until we add an extensive test suite for squashing, we'll keep the command in preview. We recommend you to confirm the correctness yourself by diffing the SQL and Metadata before and after applying the squashed migrations (we're also thinking about embedding some checks into the command itself). ```bash $ hasura migrate squash --help (PREVIEW) Squash multiple migrations leading upto the latest one into a single migration file Usage: hasura migrate squash [flags] Examples: # NOTE: This command is in PREVIEW, correctness is not guaranteed and the usage may change. # squash all migrations from version 1572238297262 to the latest one: hasura migrate squash --from 1572238297262 Flags: --from uint start squashing form this version --name string name for the new squashed migration (default "squashed") --delete-source delete the source files after squashing without any confirmation ``` ### Affected components <!-- Remove non-affected components from the list --> - CLI ### Related Issues <!-- Please make sure you have an issue associated with this Pull Request --> <!-- And then add `(close #<issue-no>)` to the pull request title --> <!-- Add the issue number below (e.g. #234) --> Close #2724, Close #2254, ### Solution and Design <!-- How is this issue solved/fixed? What is the design? --> <!-- It's better if we elaborate --> For the squash command, a state machine is implemented to track changes to Hasura metadata. After applying each action on the metadata state, a list of incremental changes is created. ### Steps to test and verify 1. Open console via cli and create some migrations. 2. Run `hasura migrate squash --from <version>` ### Limitations, known bugs & workarounds <!-- Limitations of the PR, known bugs and suggested workarounds --> <!-- Feel free to delete these comment lines --> - The `squash` command is in preview - Support for squashing from the console is WIP - Support for squashing migrations that are not committed yet is planned. - Un-tracking or dropping a table will cause inconsistent squashed down migration since console doesn't generate correct down migration. - If cascade setting is set to `true` on any of the metadata action, generated migration may be wrong
2019-10-31 05:21:15 +03:00
"github.com/pkg/errors"
2018-06-24 16:40:48 +03:00
)
/*
2018-06-24 16:40:48 +03:00
const (
sqlFile = ".sql"
yamlFile = ".yaml"
)
var ext = []string{sqlFile, yamlFile}
*/
2018-06-24 16:40:48 +03:00
type CreateOptions struct {
cli(migrations): new folder structure and squash (#3072) ### Description This PR introduces three new features: - Support for a new migrations folder structure. - Add `squash` command in preview. - ~List of migrations on the Console and ability to squash them from console.~ #### New migrations folder structure Starting with this commit, Hasura CLI supports a new directory structure for migrations folder and defaults to that for all new migrations created. Each migration will get a new directory with the name format `timestamp_name` and inside the directory, there will be four files: ```bash └── migrations ├── 1572237730898_squashed │ ├── up.sql │ ├── up.yaml │ ├── down.yaml │ └── down.sql ``` Existing files old migration format `timestamp_name.up|down.yaml|sql` will continue to work alongside new migration files. #### Squash command Lots of users have expressed their interest in squashing migrations (see #2724 and #2254) and some even built [their own tools](https://github.com/domasx2/hasura-squasher) to do squash. In this PR, we take a systematic approach to squash migrations. A new command called `migrate squash` is introduced. Note that this command is in **PREVIEW** and the correctness of squashed migration is not guaranteed (especially for down migrations). From our tests, **it works for most use cases**, but we have found some issues with squashing all the down migrations, partly because the console doesn't generate down migrations for all actions. Hence, until we add an extensive test suite for squashing, we'll keep the command in preview. We recommend you to confirm the correctness yourself by diffing the SQL and Metadata before and after applying the squashed migrations (we're also thinking about embedding some checks into the command itself). ```bash $ hasura migrate squash --help (PREVIEW) Squash multiple migrations leading upto the latest one into a single migration file Usage: hasura migrate squash [flags] Examples: # NOTE: This command is in PREVIEW, correctness is not guaranteed and the usage may change. # squash all migrations from version 1572238297262 to the latest one: hasura migrate squash --from 1572238297262 Flags: --from uint start squashing form this version --name string name for the new squashed migration (default "squashed") --delete-source delete the source files after squashing without any confirmation ``` ### Affected components <!-- Remove non-affected components from the list --> - CLI ### Related Issues <!-- Please make sure you have an issue associated with this Pull Request --> <!-- And then add `(close #<issue-no>)` to the pull request title --> <!-- Add the issue number below (e.g. #234) --> Close #2724, Close #2254, ### Solution and Design <!-- How is this issue solved/fixed? What is the design? --> <!-- It's better if we elaborate --> For the squash command, a state machine is implemented to track changes to Hasura metadata. After applying each action on the metadata state, a list of incremental changes is created. ### Steps to test and verify 1. Open console via cli and create some migrations. 2. Run `hasura migrate squash --from <version>` ### Limitations, known bugs & workarounds <!-- Limitations of the PR, known bugs and suggested workarounds --> <!-- Feel free to delete these comment lines --> - The `squash` command is in preview - Support for squashing from the console is WIP - Support for squashing migrations that are not committed yet is planned. - Un-tracking or dropping a table will cause inconsistent squashed down migration since console doesn't generate correct down migration. - If cascade setting is set to `true` on any of the metadata action, generated migration may be wrong
2019-10-31 05:21:15 +03:00
Version string
Directory string
Name string
MetaUp []byte
MetaDown []byte
SQLUp []byte
SQLDown []byte
}
func New(version int64, name, directory string) *CreateOptions {
cli(migrations): new folder structure and squash (#3072) ### Description This PR introduces three new features: - Support for a new migrations folder structure. - Add `squash` command in preview. - ~List of migrations on the Console and ability to squash them from console.~ #### New migrations folder structure Starting with this commit, Hasura CLI supports a new directory structure for migrations folder and defaults to that for all new migrations created. Each migration will get a new directory with the name format `timestamp_name` and inside the directory, there will be four files: ```bash └── migrations ├── 1572237730898_squashed │ ├── up.sql │ ├── up.yaml │ ├── down.yaml │ └── down.sql ``` Existing files old migration format `timestamp_name.up|down.yaml|sql` will continue to work alongside new migration files. #### Squash command Lots of users have expressed their interest in squashing migrations (see #2724 and #2254) and some even built [their own tools](https://github.com/domasx2/hasura-squasher) to do squash. In this PR, we take a systematic approach to squash migrations. A new command called `migrate squash` is introduced. Note that this command is in **PREVIEW** and the correctness of squashed migration is not guaranteed (especially for down migrations). From our tests, **it works for most use cases**, but we have found some issues with squashing all the down migrations, partly because the console doesn't generate down migrations for all actions. Hence, until we add an extensive test suite for squashing, we'll keep the command in preview. We recommend you to confirm the correctness yourself by diffing the SQL and Metadata before and after applying the squashed migrations (we're also thinking about embedding some checks into the command itself). ```bash $ hasura migrate squash --help (PREVIEW) Squash multiple migrations leading upto the latest one into a single migration file Usage: hasura migrate squash [flags] Examples: # NOTE: This command is in PREVIEW, correctness is not guaranteed and the usage may change. # squash all migrations from version 1572238297262 to the latest one: hasura migrate squash --from 1572238297262 Flags: --from uint start squashing form this version --name string name for the new squashed migration (default "squashed") --delete-source delete the source files after squashing without any confirmation ``` ### Affected components <!-- Remove non-affected components from the list --> - CLI ### Related Issues <!-- Please make sure you have an issue associated with this Pull Request --> <!-- And then add `(close #<issue-no>)` to the pull request title --> <!-- Add the issue number below (e.g. #234) --> Close #2724, Close #2254, ### Solution and Design <!-- How is this issue solved/fixed? What is the design? --> <!-- It's better if we elaborate --> For the squash command, a state machine is implemented to track changes to Hasura metadata. After applying each action on the metadata state, a list of incremental changes is created. ### Steps to test and verify 1. Open console via cli and create some migrations. 2. Run `hasura migrate squash --from <version>` ### Limitations, known bugs & workarounds <!-- Limitations of the PR, known bugs and suggested workarounds --> <!-- Feel free to delete these comment lines --> - The `squash` command is in preview - Support for squashing from the console is WIP - Support for squashing migrations that are not committed yet is planned. - Un-tracking or dropping a table will cause inconsistent squashed down migration since console doesn't generate correct down migration. - If cascade setting is set to `true` on any of the metadata action, generated migration may be wrong
2019-10-31 05:21:15 +03:00
v := strconv.FormatInt(version, 10)
if runtime.GOOS == "windows" {
directory = strings.TrimPrefix(directory, "/")
}
return &CreateOptions{
cli(migrations): new folder structure and squash (#3072) ### Description This PR introduces three new features: - Support for a new migrations folder structure. - Add `squash` command in preview. - ~List of migrations on the Console and ability to squash them from console.~ #### New migrations folder structure Starting with this commit, Hasura CLI supports a new directory structure for migrations folder and defaults to that for all new migrations created. Each migration will get a new directory with the name format `timestamp_name` and inside the directory, there will be four files: ```bash └── migrations ├── 1572237730898_squashed │ ├── up.sql │ ├── up.yaml │ ├── down.yaml │ └── down.sql ``` Existing files old migration format `timestamp_name.up|down.yaml|sql` will continue to work alongside new migration files. #### Squash command Lots of users have expressed their interest in squashing migrations (see #2724 and #2254) and some even built [their own tools](https://github.com/domasx2/hasura-squasher) to do squash. In this PR, we take a systematic approach to squash migrations. A new command called `migrate squash` is introduced. Note that this command is in **PREVIEW** and the correctness of squashed migration is not guaranteed (especially for down migrations). From our tests, **it works for most use cases**, but we have found some issues with squashing all the down migrations, partly because the console doesn't generate down migrations for all actions. Hence, until we add an extensive test suite for squashing, we'll keep the command in preview. We recommend you to confirm the correctness yourself by diffing the SQL and Metadata before and after applying the squashed migrations (we're also thinking about embedding some checks into the command itself). ```bash $ hasura migrate squash --help (PREVIEW) Squash multiple migrations leading upto the latest one into a single migration file Usage: hasura migrate squash [flags] Examples: # NOTE: This command is in PREVIEW, correctness is not guaranteed and the usage may change. # squash all migrations from version 1572238297262 to the latest one: hasura migrate squash --from 1572238297262 Flags: --from uint start squashing form this version --name string name for the new squashed migration (default "squashed") --delete-source delete the source files after squashing without any confirmation ``` ### Affected components <!-- Remove non-affected components from the list --> - CLI ### Related Issues <!-- Please make sure you have an issue associated with this Pull Request --> <!-- And then add `(close #<issue-no>)` to the pull request title --> <!-- Add the issue number below (e.g. #234) --> Close #2724, Close #2254, ### Solution and Design <!-- How is this issue solved/fixed? What is the design? --> <!-- It's better if we elaborate --> For the squash command, a state machine is implemented to track changes to Hasura metadata. After applying each action on the metadata state, a list of incremental changes is created. ### Steps to test and verify 1. Open console via cli and create some migrations. 2. Run `hasura migrate squash --from <version>` ### Limitations, known bugs & workarounds <!-- Limitations of the PR, known bugs and suggested workarounds --> <!-- Feel free to delete these comment lines --> - The `squash` command is in preview - Support for squashing from the console is WIP - Support for squashing migrations that are not committed yet is planned. - Un-tracking or dropping a table will cause inconsistent squashed down migration since console doesn't generate correct down migration. - If cascade setting is set to `true` on any of the metadata action, generated migration may be wrong
2019-10-31 05:21:15 +03:00
Version: v,
Directory: directory,
Name: name,
}
}
func (c *CreateOptions) SetMetaUp(data interface{}) error {
t, err := json.Marshal(data)
if err != nil {
return err
}
yamlData, err := yaml.JSONToYAML(t)
2018-06-24 16:40:48 +03:00
if err != nil {
return err
}
c.MetaUp = yamlData
return nil
}
2018-06-24 16:40:48 +03:00
func (c *CreateOptions) SetMetaUpFromFile(filePath string) error {
data, err := ioutil.ReadFile(filePath)
if err != nil {
return err
}
var metadata []interface{}
var q interface{}
err = yaml.Unmarshal(data, &q)
if err != nil {
return err
}
metadata = append(
metadata,
map[string]interface{}{
"type": "replace_metadata",
"args": q,
},
)
return c.SetMetaUp(metadata)
}
func (c *CreateOptions) SetMetaDown(data interface{}) error {
t, err := json.Marshal(data)
if err != nil {
return err
2018-06-24 16:40:48 +03:00
}
yamlData, err := yaml.JSONToYAML(t)
if err != nil {
return err
2018-06-24 16:40:48 +03:00
}
c.MetaDown = yamlData
2018-06-24 16:40:48 +03:00
return nil
}
func (c *CreateOptions) SetSQLUp(data string) error {
c.SQLUp = []byte(data)
return nil
}
func (c *CreateOptions) SetSQLUpFromFile(filePath string) error {
data, err := ioutil.ReadFile(filePath)
if err != nil {
return err
}
c.SQLUp = data
return nil
}
func (c *CreateOptions) SetSQLDown(data string) error {
c.SQLDown = []byte(data)
return nil
}
func (c *CreateOptions) Create() error {
cli(migrations): new folder structure and squash (#3072) ### Description This PR introduces three new features: - Support for a new migrations folder structure. - Add `squash` command in preview. - ~List of migrations on the Console and ability to squash them from console.~ #### New migrations folder structure Starting with this commit, Hasura CLI supports a new directory structure for migrations folder and defaults to that for all new migrations created. Each migration will get a new directory with the name format `timestamp_name` and inside the directory, there will be four files: ```bash └── migrations ├── 1572237730898_squashed │ ├── up.sql │ ├── up.yaml │ ├── down.yaml │ └── down.sql ``` Existing files old migration format `timestamp_name.up|down.yaml|sql` will continue to work alongside new migration files. #### Squash command Lots of users have expressed their interest in squashing migrations (see #2724 and #2254) and some even built [their own tools](https://github.com/domasx2/hasura-squasher) to do squash. In this PR, we take a systematic approach to squash migrations. A new command called `migrate squash` is introduced. Note that this command is in **PREVIEW** and the correctness of squashed migration is not guaranteed (especially for down migrations). From our tests, **it works for most use cases**, but we have found some issues with squashing all the down migrations, partly because the console doesn't generate down migrations for all actions. Hence, until we add an extensive test suite for squashing, we'll keep the command in preview. We recommend you to confirm the correctness yourself by diffing the SQL and Metadata before and after applying the squashed migrations (we're also thinking about embedding some checks into the command itself). ```bash $ hasura migrate squash --help (PREVIEW) Squash multiple migrations leading upto the latest one into a single migration file Usage: hasura migrate squash [flags] Examples: # NOTE: This command is in PREVIEW, correctness is not guaranteed and the usage may change. # squash all migrations from version 1572238297262 to the latest one: hasura migrate squash --from 1572238297262 Flags: --from uint start squashing form this version --name string name for the new squashed migration (default "squashed") --delete-source delete the source files after squashing without any confirmation ``` ### Affected components <!-- Remove non-affected components from the list --> - CLI ### Related Issues <!-- Please make sure you have an issue associated with this Pull Request --> <!-- And then add `(close #<issue-no>)` to the pull request title --> <!-- Add the issue number below (e.g. #234) --> Close #2724, Close #2254, ### Solution and Design <!-- How is this issue solved/fixed? What is the design? --> <!-- It's better if we elaborate --> For the squash command, a state machine is implemented to track changes to Hasura metadata. After applying each action on the metadata state, a list of incremental changes is created. ### Steps to test and verify 1. Open console via cli and create some migrations. 2. Run `hasura migrate squash --from <version>` ### Limitations, known bugs & workarounds <!-- Limitations of the PR, known bugs and suggested workarounds --> <!-- Feel free to delete these comment lines --> - The `squash` command is in preview - Support for squashing from the console is WIP - Support for squashing migrations that are not committed yet is planned. - Un-tracking or dropping a table will cause inconsistent squashed down migration since console doesn't generate correct down migration. - If cascade setting is set to `true` on any of the metadata action, generated migration may be wrong
2019-10-31 05:21:15 +03:00
path := filepath.Join(c.Directory, fmt.Sprintf("%s_%s", c.Version, c.Name))
err := os.MkdirAll(path, os.ModePerm)
if err != nil {
return err
}
// Check if data has been set in one of the files
if c.MetaUp == nil && c.MetaDown == nil && c.SQLUp == nil && c.SQLDown == nil {
return errors.New("none of the files has been set with data")
2018-06-24 16:40:48 +03:00
}
if c.MetaUp != nil {
// Create MetaUp
cli(migrations): new folder structure and squash (#3072) ### Description This PR introduces three new features: - Support for a new migrations folder structure. - Add `squash` command in preview. - ~List of migrations on the Console and ability to squash them from console.~ #### New migrations folder structure Starting with this commit, Hasura CLI supports a new directory structure for migrations folder and defaults to that for all new migrations created. Each migration will get a new directory with the name format `timestamp_name` and inside the directory, there will be four files: ```bash └── migrations ├── 1572237730898_squashed │ ├── up.sql │ ├── up.yaml │ ├── down.yaml │ └── down.sql ``` Existing files old migration format `timestamp_name.up|down.yaml|sql` will continue to work alongside new migration files. #### Squash command Lots of users have expressed their interest in squashing migrations (see #2724 and #2254) and some even built [their own tools](https://github.com/domasx2/hasura-squasher) to do squash. In this PR, we take a systematic approach to squash migrations. A new command called `migrate squash` is introduced. Note that this command is in **PREVIEW** and the correctness of squashed migration is not guaranteed (especially for down migrations). From our tests, **it works for most use cases**, but we have found some issues with squashing all the down migrations, partly because the console doesn't generate down migrations for all actions. Hence, until we add an extensive test suite for squashing, we'll keep the command in preview. We recommend you to confirm the correctness yourself by diffing the SQL and Metadata before and after applying the squashed migrations (we're also thinking about embedding some checks into the command itself). ```bash $ hasura migrate squash --help (PREVIEW) Squash multiple migrations leading upto the latest one into a single migration file Usage: hasura migrate squash [flags] Examples: # NOTE: This command is in PREVIEW, correctness is not guaranteed and the usage may change. # squash all migrations from version 1572238297262 to the latest one: hasura migrate squash --from 1572238297262 Flags: --from uint start squashing form this version --name string name for the new squashed migration (default "squashed") --delete-source delete the source files after squashing without any confirmation ``` ### Affected components <!-- Remove non-affected components from the list --> - CLI ### Related Issues <!-- Please make sure you have an issue associated with this Pull Request --> <!-- And then add `(close #<issue-no>)` to the pull request title --> <!-- Add the issue number below (e.g. #234) --> Close #2724, Close #2254, ### Solution and Design <!-- How is this issue solved/fixed? What is the design? --> <!-- It's better if we elaborate --> For the squash command, a state machine is implemented to track changes to Hasura metadata. After applying each action on the metadata state, a list of incremental changes is created. ### Steps to test and verify 1. Open console via cli and create some migrations. 2. Run `hasura migrate squash --from <version>` ### Limitations, known bugs & workarounds <!-- Limitations of the PR, known bugs and suggested workarounds --> <!-- Feel free to delete these comment lines --> - The `squash` command is in preview - Support for squashing from the console is WIP - Support for squashing migrations that are not committed yet is planned. - Un-tracking or dropping a table will cause inconsistent squashed down migration since console doesn't generate correct down migration. - If cascade setting is set to `true` on any of the metadata action, generated migration may be wrong
2019-10-31 05:21:15 +03:00
err = createFile(filepath.Join(path, "up.yaml"), c.MetaUp)
if err != nil {
return err
}
}
if c.MetaDown != nil {
// Create MetaDown
cli(migrations): new folder structure and squash (#3072) ### Description This PR introduces three new features: - Support for a new migrations folder structure. - Add `squash` command in preview. - ~List of migrations on the Console and ability to squash them from console.~ #### New migrations folder structure Starting with this commit, Hasura CLI supports a new directory structure for migrations folder and defaults to that for all new migrations created. Each migration will get a new directory with the name format `timestamp_name` and inside the directory, there will be four files: ```bash └── migrations ├── 1572237730898_squashed │ ├── up.sql │ ├── up.yaml │ ├── down.yaml │ └── down.sql ``` Existing files old migration format `timestamp_name.up|down.yaml|sql` will continue to work alongside new migration files. #### Squash command Lots of users have expressed their interest in squashing migrations (see #2724 and #2254) and some even built [their own tools](https://github.com/domasx2/hasura-squasher) to do squash. In this PR, we take a systematic approach to squash migrations. A new command called `migrate squash` is introduced. Note that this command is in **PREVIEW** and the correctness of squashed migration is not guaranteed (especially for down migrations). From our tests, **it works for most use cases**, but we have found some issues with squashing all the down migrations, partly because the console doesn't generate down migrations for all actions. Hence, until we add an extensive test suite for squashing, we'll keep the command in preview. We recommend you to confirm the correctness yourself by diffing the SQL and Metadata before and after applying the squashed migrations (we're also thinking about embedding some checks into the command itself). ```bash $ hasura migrate squash --help (PREVIEW) Squash multiple migrations leading upto the latest one into a single migration file Usage: hasura migrate squash [flags] Examples: # NOTE: This command is in PREVIEW, correctness is not guaranteed and the usage may change. # squash all migrations from version 1572238297262 to the latest one: hasura migrate squash --from 1572238297262 Flags: --from uint start squashing form this version --name string name for the new squashed migration (default "squashed") --delete-source delete the source files after squashing without any confirmation ``` ### Affected components <!-- Remove non-affected components from the list --> - CLI ### Related Issues <!-- Please make sure you have an issue associated with this Pull Request --> <!-- And then add `(close #<issue-no>)` to the pull request title --> <!-- Add the issue number below (e.g. #234) --> Close #2724, Close #2254, ### Solution and Design <!-- How is this issue solved/fixed? What is the design? --> <!-- It's better if we elaborate --> For the squash command, a state machine is implemented to track changes to Hasura metadata. After applying each action on the metadata state, a list of incremental changes is created. ### Steps to test and verify 1. Open console via cli and create some migrations. 2. Run `hasura migrate squash --from <version>` ### Limitations, known bugs & workarounds <!-- Limitations of the PR, known bugs and suggested workarounds --> <!-- Feel free to delete these comment lines --> - The `squash` command is in preview - Support for squashing from the console is WIP - Support for squashing migrations that are not committed yet is planned. - Un-tracking or dropping a table will cause inconsistent squashed down migration since console doesn't generate correct down migration. - If cascade setting is set to `true` on any of the metadata action, generated migration may be wrong
2019-10-31 05:21:15 +03:00
err = createFile(filepath.Join(path, "down.yaml"), c.MetaDown)
if err != nil {
return err
}
2018-06-24 16:40:48 +03:00
}
if c.SQLUp != nil {
// Create SQLUp
cli(migrations): new folder structure and squash (#3072) ### Description This PR introduces three new features: - Support for a new migrations folder structure. - Add `squash` command in preview. - ~List of migrations on the Console and ability to squash them from console.~ #### New migrations folder structure Starting with this commit, Hasura CLI supports a new directory structure for migrations folder and defaults to that for all new migrations created. Each migration will get a new directory with the name format `timestamp_name` and inside the directory, there will be four files: ```bash └── migrations ├── 1572237730898_squashed │ ├── up.sql │ ├── up.yaml │ ├── down.yaml │ └── down.sql ``` Existing files old migration format `timestamp_name.up|down.yaml|sql` will continue to work alongside new migration files. #### Squash command Lots of users have expressed their interest in squashing migrations (see #2724 and #2254) and some even built [their own tools](https://github.com/domasx2/hasura-squasher) to do squash. In this PR, we take a systematic approach to squash migrations. A new command called `migrate squash` is introduced. Note that this command is in **PREVIEW** and the correctness of squashed migration is not guaranteed (especially for down migrations). From our tests, **it works for most use cases**, but we have found some issues with squashing all the down migrations, partly because the console doesn't generate down migrations for all actions. Hence, until we add an extensive test suite for squashing, we'll keep the command in preview. We recommend you to confirm the correctness yourself by diffing the SQL and Metadata before and after applying the squashed migrations (we're also thinking about embedding some checks into the command itself). ```bash $ hasura migrate squash --help (PREVIEW) Squash multiple migrations leading upto the latest one into a single migration file Usage: hasura migrate squash [flags] Examples: # NOTE: This command is in PREVIEW, correctness is not guaranteed and the usage may change. # squash all migrations from version 1572238297262 to the latest one: hasura migrate squash --from 1572238297262 Flags: --from uint start squashing form this version --name string name for the new squashed migration (default "squashed") --delete-source delete the source files after squashing without any confirmation ``` ### Affected components <!-- Remove non-affected components from the list --> - CLI ### Related Issues <!-- Please make sure you have an issue associated with this Pull Request --> <!-- And then add `(close #<issue-no>)` to the pull request title --> <!-- Add the issue number below (e.g. #234) --> Close #2724, Close #2254, ### Solution and Design <!-- How is this issue solved/fixed? What is the design? --> <!-- It's better if we elaborate --> For the squash command, a state machine is implemented to track changes to Hasura metadata. After applying each action on the metadata state, a list of incremental changes is created. ### Steps to test and verify 1. Open console via cli and create some migrations. 2. Run `hasura migrate squash --from <version>` ### Limitations, known bugs & workarounds <!-- Limitations of the PR, known bugs and suggested workarounds --> <!-- Feel free to delete these comment lines --> - The `squash` command is in preview - Support for squashing from the console is WIP - Support for squashing migrations that are not committed yet is planned. - Un-tracking or dropping a table will cause inconsistent squashed down migration since console doesn't generate correct down migration. - If cascade setting is set to `true` on any of the metadata action, generated migration may be wrong
2019-10-31 05:21:15 +03:00
err = createFile(filepath.Join(path, "up.sql"), c.SQLUp)
2018-06-24 16:40:48 +03:00
if err != nil {
return err
}
}
if c.SQLDown != nil {
// Create SQLDown
cli(migrations): new folder structure and squash (#3072) ### Description This PR introduces three new features: - Support for a new migrations folder structure. - Add `squash` command in preview. - ~List of migrations on the Console and ability to squash them from console.~ #### New migrations folder structure Starting with this commit, Hasura CLI supports a new directory structure for migrations folder and defaults to that for all new migrations created. Each migration will get a new directory with the name format `timestamp_name` and inside the directory, there will be four files: ```bash └── migrations ├── 1572237730898_squashed │ ├── up.sql │ ├── up.yaml │ ├── down.yaml │ └── down.sql ``` Existing files old migration format `timestamp_name.up|down.yaml|sql` will continue to work alongside new migration files. #### Squash command Lots of users have expressed their interest in squashing migrations (see #2724 and #2254) and some even built [their own tools](https://github.com/domasx2/hasura-squasher) to do squash. In this PR, we take a systematic approach to squash migrations. A new command called `migrate squash` is introduced. Note that this command is in **PREVIEW** and the correctness of squashed migration is not guaranteed (especially for down migrations). From our tests, **it works for most use cases**, but we have found some issues with squashing all the down migrations, partly because the console doesn't generate down migrations for all actions. Hence, until we add an extensive test suite for squashing, we'll keep the command in preview. We recommend you to confirm the correctness yourself by diffing the SQL and Metadata before and after applying the squashed migrations (we're also thinking about embedding some checks into the command itself). ```bash $ hasura migrate squash --help (PREVIEW) Squash multiple migrations leading upto the latest one into a single migration file Usage: hasura migrate squash [flags] Examples: # NOTE: This command is in PREVIEW, correctness is not guaranteed and the usage may change. # squash all migrations from version 1572238297262 to the latest one: hasura migrate squash --from 1572238297262 Flags: --from uint start squashing form this version --name string name for the new squashed migration (default "squashed") --delete-source delete the source files after squashing without any confirmation ``` ### Affected components <!-- Remove non-affected components from the list --> - CLI ### Related Issues <!-- Please make sure you have an issue associated with this Pull Request --> <!-- And then add `(close #<issue-no>)` to the pull request title --> <!-- Add the issue number below (e.g. #234) --> Close #2724, Close #2254, ### Solution and Design <!-- How is this issue solved/fixed? What is the design? --> <!-- It's better if we elaborate --> For the squash command, a state machine is implemented to track changes to Hasura metadata. After applying each action on the metadata state, a list of incremental changes is created. ### Steps to test and verify 1. Open console via cli and create some migrations. 2. Run `hasura migrate squash --from <version>` ### Limitations, known bugs & workarounds <!-- Limitations of the PR, known bugs and suggested workarounds --> <!-- Feel free to delete these comment lines --> - The `squash` command is in preview - Support for squashing from the console is WIP - Support for squashing migrations that are not committed yet is planned. - Un-tracking or dropping a table will cause inconsistent squashed down migration since console doesn't generate correct down migration. - If cascade setting is set to `true` on any of the metadata action, generated migration may be wrong
2019-10-31 05:21:15 +03:00
err = createFile(filepath.Join(path, "down.sql"), c.SQLDown)
2018-06-24 16:40:48 +03:00
if err != nil {
return err
}
}
return nil
}
func (c *CreateOptions) Delete() error {
files, err := ioutil.ReadDir(c.Directory)
if err != nil {
return err
}
2018-06-24 16:40:48 +03:00
for _, fi := range files {
cli(migrations): new folder structure and squash (#3072) ### Description This PR introduces three new features: - Support for a new migrations folder structure. - Add `squash` command in preview. - ~List of migrations on the Console and ability to squash them from console.~ #### New migrations folder structure Starting with this commit, Hasura CLI supports a new directory structure for migrations folder and defaults to that for all new migrations created. Each migration will get a new directory with the name format `timestamp_name` and inside the directory, there will be four files: ```bash └── migrations ├── 1572237730898_squashed │ ├── up.sql │ ├── up.yaml │ ├── down.yaml │ └── down.sql ``` Existing files old migration format `timestamp_name.up|down.yaml|sql` will continue to work alongside new migration files. #### Squash command Lots of users have expressed their interest in squashing migrations (see #2724 and #2254) and some even built [their own tools](https://github.com/domasx2/hasura-squasher) to do squash. In this PR, we take a systematic approach to squash migrations. A new command called `migrate squash` is introduced. Note that this command is in **PREVIEW** and the correctness of squashed migration is not guaranteed (especially for down migrations). From our tests, **it works for most use cases**, but we have found some issues with squashing all the down migrations, partly because the console doesn't generate down migrations for all actions. Hence, until we add an extensive test suite for squashing, we'll keep the command in preview. We recommend you to confirm the correctness yourself by diffing the SQL and Metadata before and after applying the squashed migrations (we're also thinking about embedding some checks into the command itself). ```bash $ hasura migrate squash --help (PREVIEW) Squash multiple migrations leading upto the latest one into a single migration file Usage: hasura migrate squash [flags] Examples: # NOTE: This command is in PREVIEW, correctness is not guaranteed and the usage may change. # squash all migrations from version 1572238297262 to the latest one: hasura migrate squash --from 1572238297262 Flags: --from uint start squashing form this version --name string name for the new squashed migration (default "squashed") --delete-source delete the source files after squashing without any confirmation ``` ### Affected components <!-- Remove non-affected components from the list --> - CLI ### Related Issues <!-- Please make sure you have an issue associated with this Pull Request --> <!-- And then add `(close #<issue-no>)` to the pull request title --> <!-- Add the issue number below (e.g. #234) --> Close #2724, Close #2254, ### Solution and Design <!-- How is this issue solved/fixed? What is the design? --> <!-- It's better if we elaborate --> For the squash command, a state machine is implemented to track changes to Hasura metadata. After applying each action on the metadata state, a list of incremental changes is created. ### Steps to test and verify 1. Open console via cli and create some migrations. 2. Run `hasura migrate squash --from <version>` ### Limitations, known bugs & workarounds <!-- Limitations of the PR, known bugs and suggested workarounds --> <!-- Feel free to delete these comment lines --> - The `squash` command is in preview - Support for squashing from the console is WIP - Support for squashing migrations that are not committed yet is planned. - Un-tracking or dropping a table will cause inconsistent squashed down migration since console doesn't generate correct down migration. - If cascade setting is set to `true` on any of the metadata action, generated migration may be wrong
2019-10-31 05:21:15 +03:00
if strings.HasPrefix(fi.Name(), fmt.Sprintf("%s_", c.Version)) {
if fi.IsDir() {
path := filepath.Join(c.Directory, fi.Name())
return deleteFile(path)
}
path := filepath.Join(c.Directory, fi.Name())
err := deleteFile(path)
if err != nil {
return err
2018-06-24 16:40:48 +03:00
}
}
}
return nil
}
func createFile(fname string, data []byte) error {
file, err := os.Create(fname)
if err != nil {
return err
}
defer file.Close()
_, err = file.Write(data)
if err != nil {
return err
}
return nil
}
func deleteFile(fname string) error {
cli(migrations): new folder structure and squash (#3072) ### Description This PR introduces three new features: - Support for a new migrations folder structure. - Add `squash` command in preview. - ~List of migrations on the Console and ability to squash them from console.~ #### New migrations folder structure Starting with this commit, Hasura CLI supports a new directory structure for migrations folder and defaults to that for all new migrations created. Each migration will get a new directory with the name format `timestamp_name` and inside the directory, there will be four files: ```bash └── migrations ├── 1572237730898_squashed │ ├── up.sql │ ├── up.yaml │ ├── down.yaml │ └── down.sql ``` Existing files old migration format `timestamp_name.up|down.yaml|sql` will continue to work alongside new migration files. #### Squash command Lots of users have expressed their interest in squashing migrations (see #2724 and #2254) and some even built [their own tools](https://github.com/domasx2/hasura-squasher) to do squash. In this PR, we take a systematic approach to squash migrations. A new command called `migrate squash` is introduced. Note that this command is in **PREVIEW** and the correctness of squashed migration is not guaranteed (especially for down migrations). From our tests, **it works for most use cases**, but we have found some issues with squashing all the down migrations, partly because the console doesn't generate down migrations for all actions. Hence, until we add an extensive test suite for squashing, we'll keep the command in preview. We recommend you to confirm the correctness yourself by diffing the SQL and Metadata before and after applying the squashed migrations (we're also thinking about embedding some checks into the command itself). ```bash $ hasura migrate squash --help (PREVIEW) Squash multiple migrations leading upto the latest one into a single migration file Usage: hasura migrate squash [flags] Examples: # NOTE: This command is in PREVIEW, correctness is not guaranteed and the usage may change. # squash all migrations from version 1572238297262 to the latest one: hasura migrate squash --from 1572238297262 Flags: --from uint start squashing form this version --name string name for the new squashed migration (default "squashed") --delete-source delete the source files after squashing without any confirmation ``` ### Affected components <!-- Remove non-affected components from the list --> - CLI ### Related Issues <!-- Please make sure you have an issue associated with this Pull Request --> <!-- And then add `(close #<issue-no>)` to the pull request title --> <!-- Add the issue number below (e.g. #234) --> Close #2724, Close #2254, ### Solution and Design <!-- How is this issue solved/fixed? What is the design? --> <!-- It's better if we elaborate --> For the squash command, a state machine is implemented to track changes to Hasura metadata. After applying each action on the metadata state, a list of incremental changes is created. ### Steps to test and verify 1. Open console via cli and create some migrations. 2. Run `hasura migrate squash --from <version>` ### Limitations, known bugs & workarounds <!-- Limitations of the PR, known bugs and suggested workarounds --> <!-- Feel free to delete these comment lines --> - The `squash` command is in preview - Support for squashing from the console is WIP - Support for squashing migrations that are not committed yet is planned. - Un-tracking or dropping a table will cause inconsistent squashed down migration since console doesn't generate correct down migration. - If cascade setting is set to `true` on any of the metadata action, generated migration may be wrong
2019-10-31 05:21:15 +03:00
return os.RemoveAll(fname)
2018-06-24 16:40:48 +03:00
}
func GotoCmd(m *migrate.Migrate, v uint64, direction string) error {
return m.Migrate(v, direction)
}
func UpCmd(m *migrate.Migrate, limit int64) error {
if limit >= 0 {
return m.Steps(limit)
} else {
return m.Up()
}
}
func DownCmd(m *migrate.Migrate, limit int64) error {
if limit >= 0 {
return m.Steps(-limit)
} else {
return m.Down()
}
}
cli(migrations): new folder structure and squash (#3072) ### Description This PR introduces three new features: - Support for a new migrations folder structure. - Add `squash` command in preview. - ~List of migrations on the Console and ability to squash them from console.~ #### New migrations folder structure Starting with this commit, Hasura CLI supports a new directory structure for migrations folder and defaults to that for all new migrations created. Each migration will get a new directory with the name format `timestamp_name` and inside the directory, there will be four files: ```bash └── migrations ├── 1572237730898_squashed │ ├── up.sql │ ├── up.yaml │ ├── down.yaml │ └── down.sql ``` Existing files old migration format `timestamp_name.up|down.yaml|sql` will continue to work alongside new migration files. #### Squash command Lots of users have expressed their interest in squashing migrations (see #2724 and #2254) and some even built [their own tools](https://github.com/domasx2/hasura-squasher) to do squash. In this PR, we take a systematic approach to squash migrations. A new command called `migrate squash` is introduced. Note that this command is in **PREVIEW** and the correctness of squashed migration is not guaranteed (especially for down migrations). From our tests, **it works for most use cases**, but we have found some issues with squashing all the down migrations, partly because the console doesn't generate down migrations for all actions. Hence, until we add an extensive test suite for squashing, we'll keep the command in preview. We recommend you to confirm the correctness yourself by diffing the SQL and Metadata before and after applying the squashed migrations (we're also thinking about embedding some checks into the command itself). ```bash $ hasura migrate squash --help (PREVIEW) Squash multiple migrations leading upto the latest one into a single migration file Usage: hasura migrate squash [flags] Examples: # NOTE: This command is in PREVIEW, correctness is not guaranteed and the usage may change. # squash all migrations from version 1572238297262 to the latest one: hasura migrate squash --from 1572238297262 Flags: --from uint start squashing form this version --name string name for the new squashed migration (default "squashed") --delete-source delete the source files after squashing without any confirmation ``` ### Affected components <!-- Remove non-affected components from the list --> - CLI ### Related Issues <!-- Please make sure you have an issue associated with this Pull Request --> <!-- And then add `(close #<issue-no>)` to the pull request title --> <!-- Add the issue number below (e.g. #234) --> Close #2724, Close #2254, ### Solution and Design <!-- How is this issue solved/fixed? What is the design? --> <!-- It's better if we elaborate --> For the squash command, a state machine is implemented to track changes to Hasura metadata. After applying each action on the metadata state, a list of incremental changes is created. ### Steps to test and verify 1. Open console via cli and create some migrations. 2. Run `hasura migrate squash --from <version>` ### Limitations, known bugs & workarounds <!-- Limitations of the PR, known bugs and suggested workarounds --> <!-- Feel free to delete these comment lines --> - The `squash` command is in preview - Support for squashing from the console is WIP - Support for squashing migrations that are not committed yet is planned. - Un-tracking or dropping a table will cause inconsistent squashed down migration since console doesn't generate correct down migration. - If cascade setting is set to `true` on any of the metadata action, generated migration may be wrong
2019-10-31 05:21:15 +03:00
func SquashCmd(m *migrate.Migrate, from uint64, version int64, name, directory string) (versions []int64, err error) {
versions, upMeta, upSql, downMeta, downSql, err := m.Squash(from)
if err != nil {
return
}
createOptions := New(version, name, directory)
if len(upMeta) != 0 {
byteUp, err := yaml.Marshal(upMeta)
if err != nil {
return versions, errors.Wrap(err, "cannot unmarshall up query")
}
createOptions.MetaUp = byteUp
}
if len(downMeta) != 0 {
byteDown, err := yaml.Marshal(downMeta)
if err != nil {
return versions, errors.Wrap(err, "cannot unmarshall down query")
}
createOptions.MetaDown = byteDown
}
createOptions.SQLUp = upSql
createOptions.SQLDown = downSql
err = createOptions.Create()
if err != nil {
return versions, errors.Wrap(err, "cannot create migration")
}
return
}
func GotoVersionCmd(m *migrate.Migrate, gotoVersion int64) error {
return m.GotoVersion(gotoVersion)
}