Hey @cdcarson, I appreciate you opening up this issue!

I had a question with your implementation and suggestion. What is stopping you from using the field.table and the field.name field that is available on the Field type in order to have that special handling at the global connection-level? This way, you don't have to remember to always pass this custom cast function on a per-execution basis and know that for that specific table and column, it will always be casted correctly. Is that still limiting?

Hey @yquansah! Thanks for opening this issue.

We've gone ahead and cut a new release that removes these assumptions about the name being main, now defaulting to either the parent branch (if present) or the default branch of the database. Let us know if you run into any more hiccups!

Repro steps:

$ pscale database create test-db
Database test-db was successfully created.

View this database in the browser: https://app.planetscale.com/yqsummon/test-db
$ pscale branch create test-db feat-branch
Branch feat-branch was successfully created.

View this branch in the browser: https://app.planetscale.com/yqsummon/test-db/feat-branch
$ pscale branch promote test-db feat-branch
Branch feat-branch in test-db was successfully promoted.
$ pscale branch list test-db
  NAME          PARENT BRANCH   PRODUCTION   READY   CREATED AT      UPDATED AT
 ------------- --------------- ------------ ------- --------------- ---------------
  main          n/a             No           Yes     2 minutes ago   1 minute ago
  feat-branch   n/a             Yes          Yes     1 minute ago    9 seconds ago

$ pscale deploy-request create test-db main
Error: Database branch main is not a production branch.
$ pscale branch delete test-db main
? Please type test-db/main to confirm: test-db/main
Branch main was successfully deleted from test-db.
$ pscale branch create test-db another-feat-branch
Branch another-feat-branch was successfully created.

View this branch in the browser: https://app.planetscale.com/yqsummon/test-db/another-feat-branch
$ pscale branch list test-db
  NAME                  PARENT BRANCH   PRODUCTION   READY   CREATED AT       UPDATED AT
 --------------------- --------------- ------------ ------- ---------------- ----------------
  feat-branch           n/a             Yes          Yes     3 minutes ago    2 minutes ago
  another-feat-branch   feat-branch     No           No      11 seconds ago   11 seconds ago

$ pscale deploy-request create test-db another-feat-branch
Error: Database branch main is invalid or does not exist.

It seems as though main branch must be present in order for a successful deploy request to be created from one branch to the primary branch (which is main in this case). Is it the case that the main branch needs to be present? Or can any branch serve as the primary branch of which feature branches branch off of in order to create a deploy request?

It seems to suggest that you can make any branch a production branch as I did with feat-branch, when I promoted it.

Remove main as default branch for the deploy request (#614)

• Add an into flag for a deploy request.

• Remove assumptions about the default into branch, deprecate --deploy-to in favor of --into.

• Update planetscale-go.

• Add more tests.

This pull request removes main as the default for creating a deploy request. This way, we can fallback to using the parent of the specified branch.

After some discussion, --deploy-to is also a confusing name for a flag, so we've renamed this flag to --into and marked the previous one as deprecated.

Fixes https://github.com/planetscale/cli/issues/608

Add more tests.

This pull request removes main as the default for creating a deploy request. This way, we can fallback to using the parent of the specified branch.

Closes https://github.com/planetscale/cli/issues/608

Add omit empty for a deploy request branch.

Merge pull request #149 from planetscale/iheanyi/omit-empty-for-into-branch

Add omit empty for a deploy request branch.

Adds omitempty into the IntoBranch field so that it does not send over a blank string.

Adds omitempty into the IntoBranch field so that it does not send over a blank string.

Hi, just curious as I am learning as well...

When is this function ever called in the code?

func (r *Resolver) Hello(ctx context.Context, args struct{ Name string }) (string, error) {
	request := &api.SayHelloReq{
		Name: args.Name,
	}

	res, err := r.helloSvc.SayHello(ctx, request)
	if err != nil {
		return "", err
	}

	return res.Message, nil
}

the query defines a lowercase hello() function, just not sure how graphql makes the link between hello() and Hello()

This changes the CLI to use RequestPromotion instead of Promote.

Change Promote function to RequestPromotion for posterity.

Fix up method names.

Merge pull request #148 from planetscale/iheanyi/change-promote-to-request-promotion

Rename Promote function to RequestPromotion

This pull request changes to RequestPromotion. The reason is that branch promotion is an async action. Promote implies that it is synchronous, RequestPromotion more accurately highlights what it is actually doing.

This pull request changes to RequestPromotion. The reason is that branch promotion is an async action. Promote implies that it is synchronous, RequestPromotion more accurately highlights what it is actually doing.

Fix up method names.