ONLY ModelMutations.update() for GraphQL not working from Flutter-CodePudding

https://docs.amplify.aws/lib/graphqlapi/mutate-data/q/platform/flutter/#run-a-mutation

Referencing the official, I've been trying to .update() an item I was successfully able to add through the .create(). The mutation response that I receive shows me a successful attempt, but there are no actual updates being made.

Tried to make simpler changes, such as switching bools, but same result.

Then I remembered that making changes from lambda required the .key() method to check the primary key of the item to be updated. Is there a same check mechanism from flutter/Dart? If so, what would the implementation of that look like?

I can confirm that ModelMutations.update(newClass) contains the correct Class and that the version field of the item in DynamoDB Console is being incremented per request, just not the actual item.

CodePudding user response：

I tried a few things and got it to work, so leaving a trail for future users. Maybe most people not as beginner like me.

Conlusion first, all I did was;

delete DataStore that I was using separately with GraphQL API. Maybe you might not need to delete everything, but I got rid off plugin, package, etc.
Disable Conflict Detection from Amplify CLI

After doing this, the mutation response began returning an error (it didn't before) and led to easy debugging from there.

There are some resources that suggest passing _version as the parameter when using DataStore with GraphQL, but the implementation of .copyWith() on codegen models in Flutter didn't consider this a valid index as the items were added using the GraphQLAPI and hence in my case, it was easier to simply delete DataStore.

Some other resources I used; (https://github.com/aws-amplify/amplify-js/issues/10664) (https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Programming.Errors.html)

Another suggestion, although a very obvious one that took me a while to try, is to log response.errors from mutation response.

CodePudding user response：

The short answer to whether the .update() method parameter requires the primary_key field is YES. Reason being, with the primary_key, the mutation response is a success, but without it, I get null check operator used on a null value, which I believe (without any documented evidence) indicates a scenario where the API either failed to return the existing item in the DDB table or simply returned None/null. The same null message is recorded when a different key is specified.

As to why the update doesn't occur, I am still at a loss. Particularly as other methods such as .create() seem to be working just fine when replaced.