clarkie / dynogels

DynamoDB data mapper for node.js. Originally forked from https://github.com/ryanfitz/vogels

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

ValidationException on .destroy() method

Serjkee opened this issue · comments

commented

I'm trying to delete an item from the base and i get validation exception, though it works as expected for create and get methods.

My model:

const Schema = {
  _id: Joi.string().required(),
  data: Joi.string().required(),
  sourceId: Joi.string().required(),
  techId: Joi.string(),
  timestamp: Joi.string().required(),
};

const Model = {
  hashKey: '_id',
  timestamps: false,
  schema: Schema,
};

export const commentsModel = dynogels.define('global-statistics-comments', Model);

My function:

export const deleteComment = async () => {
  try {
    const receivedObj = {
      _id: 'google_2016-01-02T04:25:00.400Z_vue',
      timestamp: 1451708700,
      data: 'Framework',
      sourceId: 'google',
      techId: 'vue'
    }

    await commentsModel.destroy(receivedObj._id, function (err) {
      throw new Error(err);
    })
  } catch (error) {
    throw new Error(error);
  }
};

The error:

Error: ValidationException: The provided key element does not match the schema
at /var/task/handler.js:10:2003759
at n.sendRequest (/var/task/handler.js:9:258287)
at constructor.n.(anonymous function).call (/var/task/handler.js:9:252981)
at constructor.<anonymous> (/var/task/handler.js:9:393913)
at constructor.callListeners (/var/task/handler.js:9:246302)
at constructor.emit (/var/task/handler.js:9:246012)
at constructor.emitEvent (/var/task/handler.js:9:396757)
at constructor.e (/var/task/handler.js:9:392330)
at r.runTo (/var/task/handler.js:9:398568)
at /var/task/handler.js:9:398773
at constructor.<anonymous> (/var/task/handler.js:9:392599)
at constructor.<anonymous> (/var/task/handler.js:9:396812)
at constructor.callListeners (/var/task/handler.js:9:246408)
at constructor.emit (/var/task/handler.js:9:246012)
at constructor.emitEvent (/var/task/handler.js:9:396757)
at constructor.e (/var/task/handler.js:9:392330)

Please let me know if any additional information needs to be provided.
Notice: I use dynogels-promisified, but the issue is the same for destroyAsync method.

@Serjkee I cannot reproduce this bug. I created a DynamoDB table using this same schema and was able to successfully create and then destroy the example record (after changing timestamp to be a string, as declared in the schema).

The line commentsModel.destroy(receivedObj._id, console.log); ran without error (null was logged indicating no error) and the record was removed from the table, as expected.

Usually you see "The provided key element does not match the schema" when the value is not of the expected type; e.g. it's null, undefined, or is an object that is missing the required key value(s). (For example, if your table has a range key then you would see this error because you only provided the hash key.)

Please give us a complete test case along with a working schema that can be used to create a DynamoDB table that exactly matches your DynamoDB table.

commented

Hi @cdhowie

Thanks for the such fast response. I've managed to successfully resolve this one. The issue was with that i didn't specify rangeKey in my schema. In the docs we can see that rangeKey must be passed so i tried, but without specifying it in my schema. It wasn't clear for me at the first glance from the delete section in docs, so the issue is made on my own :)

Is it a good idea to add for delete (and update) in the description block: 'You delete items in DynamoDB using the hashkey of model If your model uses both a hash and range key, then both need to be provided' something like "Ensure that the rangeKey is specified in your schema"? Possibly, I'm not the one who made such mistake :) What do you think?

Once again, thanks for your help. The issue can be closed :)

@Serjkee Deletion in the docs already provides an example of deleting a record where the schema has a range key. I'm not sure what else we could add to the section to make that clearer.

I don't think that explicitly stating "make sure your schema is correct" makes much sense; we'd have to do that multiple times all over the documentation. I think it's a reasonable assumption that your schema should be correct; if it's not, all sorts of other problems might also happen.

As requested I'll close this issue. Let us know if you run into any other problems.