Git Product home page Git Product logo

atlas-go-sdk's People

Contributors

datdao avatar dorav avatar giautm avatar masseelch avatar noamcattan avatar ronenlu avatar rotemtam avatar snokpok avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

atlas-go-sdk's Issues

Add format option to SchemaApplyParams

params.Format is missing, thwarting us from providing a migration tool agnostic API.

// SchemaApplySlice runs the 'schema apply' command for multiple targets.
func (c *Client) SchemaApplySlice(ctx context.Context, params *SchemaApplyParams) ([]*SchemaApply, error) {
	args := []string{"schema", "apply", "--format", "{{ json . }}"}
	if params.Env != "" {
		args = append(args, "--env", params.Env)
	}
	if params.ConfigURL != "" {
		args = append(args, "--config", params.ConfigURL)
	}
	if params.URL != "" {
		args = append(args, "--url", params.URL)
	}
	if params.To != "" {
		args = append(args, "--to", params.To)
	}
	if params.DryRun {
		args = append(args, "--dry-run")
	} else {
		args = append(args, "--auto-approve")
	}
	if params.TxMode != "" {
		args = append(args, "--tx-mode", params.TxMode)
	}
	if params.DevURL != "" {
		args = append(args, "--dev-url", params.DevURL)
	}
	if len(params.Schema) > 0 {
		args = append(args, "--schema", strings.Join(params.Schema, ","))
	}
	if len(params.Exclude) > 0 {
		args = append(args, "--exclude", strings.Join(params.Exclude, ","))
	}
	args = append(args, params.Vars.AsArgs()...)
	return jsonDecodeErr[SchemaApply](newSchemaApplyError)(c.runCommand(ctx, args))
}

Migration error reporting is confusing

If a migration fails, this module seems to silently report success.

Why?

Even if the atlas command returns a non-zero exit code, the Apply and similar methods always return a nil error, as long as it can parse the output of the command as JSON:

if cliErr := (cliError{}); errors.As(err, &cliErr) && cliErr.stderr == "" {
r = strings.NewReader(cliErr.stdout)
err = nil
}
return jsonDecode[MigrateApply](r, err)

It seems that API users have to check the .Error property on what one would expect to be the success output to check for errors, in addition to the "normal" error return.

This is confusing and error-prone.

missing flag in atlasexec.ApplyParams

the struct atlasexec.ApplyParams doesn't have field for the flag --allow-dirty, which is present in the cli tool

'atlas migrate apply' reads the migration state of the connected database and computes what migrations are pending.
It then attempts to apply the pending migration files in the correct order onto the database.
The first argument denotes the maximum number of migration files to apply.
As a safety measure 'atlas migrate apply' will abort with an error, if:
  - the migration directory is not in sync with the 'atlas.sum' file
  - the migration and database history do not match each other

If run with the "--dry-run" flag, atlas will not execute any SQL.

Usage:
  atlas migrate apply [flags] [amount]

Examples:
  atlas migrate apply -u "mysql://user:pass@localhost:3306/dbname"
  atlas migrate apply --dir "file:///path/to/migration/directory" --url "mysql://user:pass@localhost:3306/dbname" 1
  atlas migrate apply --env dev 1
  atlas migrate apply --dry-run --env dev 1

Flags:
  -u, --url string                [driver://username:password@address/dbname?param=value] select a resource using the URL format
      --dir string                select migration directory using URL format (default "file://migrations")
      --format string             Go template to use to format the output
      --revisions-schema string   name of the schema the revisions table resides in
      --dry-run                   print SQL without executing it
      --lock-timeout duration     set how long to wait for the database lock (default 10s)
      --baseline string           start the first migration after the given baseline version
      --tx-mode string            set transaction mode [none, file, all] (default "file")
      --allow-dirty               allow start working on a non-clean database
  -h, --help                      help for apply

Global Flags:
  -c, --config string        select config (project) file using URL format (default "file://atlas.hcl")
      --env string           set which env from the config file to use
      --var <name>=<value>   input variables (default [])

Error handling in `(c *Client) runCommand` is flawed

Full function:

// runCommand runs the given command and returns its output.
func (c *Client) runCommand(ctx context.Context, args []string) (io.Reader, error) {
	var stdout, stderr bytes.Buffer
	cmd := exec.CommandContext(ctx, c.execPath, args...)
	cmd.Dir = c.workingDir
	// Set ATLAS_NO_UPDATE_NOTIFIER=1 to disable the update notifier.
	// use os.Environ() to avoid overriding the user's environment.
	cmd.Env = append(os.Environ(), "ATLAS_NO_UPDATE_NOTIFIER=1")
	cmd.Stderr = &stderr
	cmd.Stdout = &stdout
	if err := cmd.Run(); err != nil {
		return nil, cliError{
			stderr: strings.TrimSpace(stderr.String()),
			stdout: strings.TrimSpace(stdout.String()),
		}
	}
	return &stdout, nil
}

Problem:

if err := cmd.Run(); err != nil {
	return nil, cliError{
		stderr: strings.TrimSpace(stderr.String()),
		stdout: strings.TrimSpace(stdout.String()),
	}
}

This error handler throws away the err value from cmd.Run(), assuming that the error comes from atlas, not the execution itself.

image

I ended up debugging just to find out that I forgot to install atlas. This should be fixed by deferring to the exec error when it is populated, or maybe including both.

MigrateApply throws an error, even when the migrations are successful

Current version: v0.3.0

For example, here's my code:

// Run `atlas migrate apply` on a SQLite database under /tmp.
res, err := client.MigrateApply(context.Background(), &atlasexec.MigrateApplyParams{
Env: "prod",
})

fmt.Println("res: ", res)
repr.Println(err)

I have exported the ATLAS_TOKEN, ATLAS_PROJECT and DATABASE_URL env vars.

Irrespective of whether the actual migration operation is successful or not, res is always nil and err is always populated with

atlasexec.cliError{
  stdout: "...logs of what the 'atlas migrate apply' command outputs"
}

Expectation is that on successful migration (even if that means no new migration files are to be applied), the res variable should be populated with a useful success message & the err variable should be nil.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.