Amplify-js: Datastore sync doesn't delete items in dynamo with sort and partition key

Created on 11 Dec 2019  ·  7Comments  ·  Source: aws-amplify/amplify-js

Describe the bug
When calling Datstore.delete with an item containing a partition and sort key, the item is deleted locally, but a warning is given in the console and the dynamo record remains unchanged.

To Reproduce
Steps to reproduce the behavior:

  1. Create react app
  2. Add a schema like below:
type Task @model @key(fields: ["customer", "id"]) {
  customer: String!
  id: ID!
  title: String!
  description: String
  status: String
}
  1. run npx amplify-app
  2. run npm run amplify-modelgen
  3. run npm i @aws-amplify/core @aws-amplify/datastore
  4. run npm run amplify-push
  5. run app code similar to below:
  6. Create a new record and then delete, you should see a warning with this message in the body: Variable 'input' has coerced Null value for NonNull type 'String!'
import React, { useEffect, useState } from "react";
import logo from "./logo.svg";
import "./App.css";

import Amplify from "@aws-amplify/core";
import { DataStore, Predicates } from "@aws-amplify/datastore";

import { Task } from "./models";

import awsConfig from "./aws-exports";
Amplify.configure(awsConfig);

function onCreate() {
  DataStore.save(
    new Task({
      customer: "1",
      title: `New title ${Date.now()}`,
      description:"new task",
      status: "soon"
    })
  );
}

async function listTasks(setTasks) {
  const tasks = await DataStore.query(Task, Predicates.ALL);
  setTasks(tasks);
}
const deleteTask = async (task) => {
  await DataStore.delete(task);
}

function App() {

  const [tasks, setTasks] = useState([]);

  useEffect( () => {

    const subscription = DataStore.observe(Task).subscribe(msg => {
      listTasks(setTasks);
    });
    listTasks(setTasks);
    return () => subscription.unsubscribe();
  }, []);

  return (
    <div className="App">
      <header className="App-header">
        <img src={logo} className="App-logo" alt="logo" />
      <div>
        <input type="button" value="NEW" onClick={() => { onCreate(); } } />
      </div>
      <table border="1">
        <thead>
          <tr><td>Id</td><td>Title</td><td>Status</td><td></td></tr>
        </thead>
        <tbody>
          {tasks.map( (item,i) => {
            return <tr key={i}><td>{item.id.substring(0,4)}</td><td>{item.title}</td><td>{item.status}</td><td><button onClick={() => deleteTask(item)}>delete</button></td></tr>
          } )}
        </tbody>
      </table>

      </header>
    </div>
  );
}

export default App;
DataStore pending-close-response-required

Most helpful comment

So when using custom index, the fields corresponding to partitionKey and sortKey are not sent within the GraphQL request. Just the id

@lazy-var we are tracking this as a feature request, we can provide an ETA once we are clear with the design and integration with the CLI

All 7 comments

Hi! I have reported the same new API/Datastore plugins behaviour miss-alignment here: aws-amplify/amplify-cli#3109

On iOS it’s because delete GraphQL operations are ‘hardcoded’ including only “id” field value as $input on the call.
I suppose it’s the same problem on Android/JS.
So when using custom index, the fields corresponding to partitionKey and sortKey are not sent within the GraphQL request. Just the id

So when using custom index, the fields corresponding to partitionKey and sortKey are not sent within the GraphQL request. Just the id

@lazy-var we are tracking this as a feature request, we can provide an ETA once we are clear with the design and integration with the CLI

I am also having same problem but with @connection with @key. I have made separate issue #5088 here

Can you take a look at the latest docs for Relational modeling with DataStore and use the latest library version? We made some improvements to the CLI, the library on how it handles this internally, and tried to be explicit about schemas in the documentation including how to use @key.

I will try to take a look this weekend.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This issue has been automatically closed because of inactivity. Please open a new issue if are still encountering problems.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

josoroma picture josoroma  ·  3Comments

ldgarcia picture ldgarcia  ·  3Comments

callmekatootie picture callmekatootie  ·  3Comments

cgarvis picture cgarvis  ·  3Comments

rygo6 picture rygo6  ·  3Comments