By using AWS re:Post, you agree to the Terms of Use

Amplify push overriding my schema.graphql schema for an input type?

0

Hello, below is my schema.graphql:

type User @model(subscriptions: null) @key(fields: ["username"]) {
  username: String!
  name: String
  email: AWSEmail
  userID: ID!
}

type Code @model @key(fields: ["owner", "status", "createdAt"]) {
  owner: String!
  code: String!
  status: Status!
  codeID: ID!
  createdAt: AWSDateTime!
}

enum Status {
  USED
  UNUSED
  UNKNOWN
}

input CreateUserInput {
  username: String!
  name: String
  email: AWSEmail
  userID: ID
}

input CreateCodeInput {
	owner: String!
	code: String!
	status: Status!
	codeID: ID
	createdAt: AWSDateTime
}

The schema is fairly simple, and I am relying on Amplify to create all the queries, mutations, and subscriptions. I added the input schemas for CreateUserInput and CreateCodeInput because of the ID fields and the createdAt fields. Those fields are required for my current business logic, but I try to assign them in a custom resolver for those "Create" mutation requests using the applicable $util. calls. I am confident the resolvers are working correctly because of what I describe below.

When I perform an "amplify push" on the CLI, everything updates as expected, but the custom input schema for CreateCodeInput seems to get overridden, and makes createdAt required again. When I check in the AppSync console I see "createdAt: AWSDateTime!"...

This required field breaks my app logic which does not pass an AWSDateTime, instead relying on the resolver to generate that. If I remove the "!" in the AppSync console, my app logic works as expected.

Can anyone help me figure out how to make "amplify push" work from the CLI so I don't have to go into the console every time I push an update?

Edited by: aj177 on May 27, 2020 4:02 PM

asked 2 years ago41 views
2 Answers
0

Today I updated the amplify CLI and my existing schema.graphql file created the expected schema in the Amplify Console automatically.

Granted, I also had to perform an "amplify remove api" and recreate the api via "amplify add api" because I had let the API key expire and all the other fixes seemed like cheap hacks (eyeroll emoji).

Not sure which of those two items fixed the behavior, but everything seems to be working as expected now. Hopefully this helps others!

answered 2 years ago
0

See my reply to myself - I suspect a CLI update fixed the issue.

answered 2 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions