amplify-cli: Including _version in delete requests, unable to filter _deleted items from list response.

Which Category is your question related to? Using AWS Amplify API to delete items through AWS Appsync

Amplify CLI Version 4.18.1

What AWS Services are you utilizing? AWS Appsync, DynamoDB

Provide additional details e.g. code snippets While using API.graphql to delete items from my database I have 2 following issue:

Issue # 1:

Here is my request to delete a photo from the frontend:

API.graphql(graphqlOperation(mutations.deletePhoto, {
      input: {
        id: photoId,
        _version: 1,
      }
    })) as unknown as {
      data: DeletePhotoMutation
    }

Currently, there’s no way for me delete an item without including the _version of the item without running into an error:

errorType: "ConflictUnhandled"
message: "Conflict resolver rejects mutation."

Is this intended? Or am I missing something.

Issue # 2 :

When I successfully deleted the item using the API by adding in the _version attributes, I verified that the deleted attributes in DynamoDB is false,

Screen Shot 2020-04-28 at 8 51 43 PM

When I list all the items again, I couldn’t find a way to filter out deleted items from server side. The generated types for the filter is like so:

export type ModelPhotoFilterInput = {
  id?: ModelIDInput | null,
  albumId?: ModelIDInput | null,
  bucket?: ModelStringInput | null,
  and?: Array< ModelPhotoFilterInput | null > | null,
  or?: Array< ModelPhotoFilterInput | null > | null,
  not?: ModelPhotoFilterInput | null,
};

So now I have to fetch all items from serverside and filter deleted items out on the front end like so

const listPhotosByAlbum = async (input: ListPhotosByAlbumQueryVariables): Promise<any> => {
  const response = await API.graphql(graphqlOperation(queries.listPhotosByAlbum, input)) as unknown as {
    data: ListPhotosByAlbumQuery
  };
  return response.data.listPhotosByAlbum.items.filter(item => item._deleted !== true);
};

which isn’t ideal considering the number of deleted items can grow indefinitely and slow down the response.

Appreciate if anyone can share their experience.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 19 (5 by maintainers)

Most upvoted comments

Same issue, shouldn’t Appsync Resolvers filter out _deleted=true ?

jesper-bylund on Apr 30, 2020

I have to agree with Mentioum & drixta, seems like an unnecessary pain to have filter out deleted items on the client side, and not enable a query of non-deleted items from the server. I’m running into this same issue, and it’s too bad that I can’t filter or do something to query out the _deleted items server side via : listBlogs(filter: {type: {notContains: “_deleted”}}), I guess I will look at creating my own field “trash”, move the item to the “trash”, delete it, and then filter it out non trash from my main queries, but that seems like lot of extra unnecessary steps.

LawrenceNorman on Jul 1, 2020

@LawrenceNorman @Mentioum are you using the API Category in your app client code? As mentioned above the reason the items which are marked for deletion are coming through is because you have syncing enabled on your endpoint which is not designed to work with the API category but rather the DataStore category. When you’re using DataStore it uses this metadata to remove the items from the local storage medium, so no extra filtering is needed there. The API category from your client code isn’t designed for synching which is why you shouldn’t enable it if you’re trying to interface with your GraphQL endpoint directly.

Could you please indicate how to disable the sync if it was enabled accidentally at the beginning?

ivenxu on Jul 2, 2020

If you’re using both, then you’re going to have to independently track versions in your app state (sending the current version when you perform update mutations with API directly) and handling deletion filtering locally. Using both categories together isn’t something we fully support OOTB today. It’s on the roadmap, but to be transparent it’s a bit away.

undefobj on Jul 2, 2020

Good to know that having both DataStore and GraphQL API going together might cause issues if you’re not careful. @ivenxu I kept running into issues with deletion and after reading https://github.com/aws-amplify/amplify-cli/issues/2384 I figured out I had to resort to: amplify api remove followed by amplify add api and then I just put my graphql db on an api key and opted to not configure conflict detection, and now my graphql mutations seem to be working well.

LawrenceNorman on Jul 7, 2020

@LawrenceNorman @Mentioum are you using the API Category in your app client code? As mentioned above the reason the items which are marked for deletion are coming through is because you have syncing enabled on your endpoint which is not designed to work with the API category but rather the DataStore category. When you’re using DataStore it uses this metadata to remove the items from the local storage medium, so no extra filtering is needed there. The API category from your client code isn’t designed for synching which is why you shouldn’t enable it if you’re trying to interface with your GraphQL endpoint directly.

undefobj on Jul 1, 2020