[BUG] TypeMismatch error when attribute is called 'model'

[gmaragao]

Summary:

When trying to create an item using a schema, dynamoose triggers a TypeMismatch error when using an attribute called 'model'. It works fine with any other attribute name.

Code sample:

Schema

const dynamoose = require('dynamoose');

const testSchema = new dynamoose.Schema({
    _id: {
        type: String,
        hashKey: true,
    },
    model: {
        type: Array,
        schema: [
            {
                type: Object,
                schema: {
                    _id: String,
                    text: String,
                },
            },
        ],
    }
}, { saveUnkown: true, create:true }
);

module.exports = dynamoose.model('ModelTest', testSchema);

Model

// Code here

General

index.js

const dynamoose = require('dynamoose');
const Model = require('./model')
const { sdk } = dynamoose.aws;

sdk.config.update({
    region: 'fake',
});

dynamoose.aws.ddb.local('http://localhost:8001');


async function runTest() {

    try {
        const newModel = await Model.create(
            {   
                _id: '123',  
                model: [
                    { _id: '12345678', text: 'someText' }
                ]
            }
        );

        console.log(newModel);
        
    } catch(err){
        console.log(err)
    }

}


runTest();

Current output and behavior (including stack trace):

TypeMismatch: Expected model to be of type array, instead found type object.
at checkTypeFunction (...\node_modules\dynamoose\lib\Document.ts:302:11)
at Array.map ()
at Function. (...\node_modules\dynamoose\lib\Document.ts:323:111)
at Generator.next ()
at fulfilled (...\node_modules\dynamoose\dist\Document.js:5:58)

Expected output and behavior:

Output behavior when using the attribute as 'model1'

Document {
  _id: '123',
  model1: [ { _id: '12345678', text: 'someText' } ]
}

Environment:

Operating System: Windows
Operating System Version: Windows 10 Enterprise
Node.js version (v12.18.2):
NPM version: (6.14.5):
Dynamoose version: 2.3.0

Other information (if applicable):

Other:

• I have read through the Dynamoose documentation before posting this issue
• I have searched through the GitHub issues (including closed issues) and pull requests to ensure this issue has not already been raised before
• I have searched the internet and Stack Overflow to ensure this issue hasn't been raised or answered before
• I have tested the code provided and am confident it doesn't work as intended
• I have filled out all fields above
• I am running the latest version of Dynamoose

[fishcharlie]

@gmaragao I don't see this being addressed anytime soon. This will require a strong line by line assessment of the project to determine what we need to do here. I don't think this will happen anytime soon.

If you would like to attempt to put up a PR for this, that'd be awesome.

[KyleMit]

Just adding some debugging

This throws the invalid error from within Document.objectFromSchema.checkTypeFunction which checks for validation inside utils/dynamoose/getValueTypeCheckResult.ts

Of the available schema entries, I get this thrown on the following set:

When validating item 42, dynamoose is expecting a string (S), but throws a validation error when it sees the object {S: 'ef'}. But this is stored as a string in the database - dyanmoose is the one converting it into that value.

Related Issues

• Schema types mismatch #854
• TypeMismatch: Expected xxx to be of type object, instead found type object #928
• Expected 'property' to be of type string, instead found type object - Dynamoose
• Expected xxx to be of type object, instead found type object

[jccampanero]

As @gmaragao indicated, I think the problem is related with the name of the attribute, model.

The following code in Document.ts is the one which is overwriting the model property:

Object.defineProperty(this, "model", {
  "configurable": false,
  "value": model
});

In a simple test case, derived from this stack overflow question, this is how the Document looks like before the execution of that code:

And after the execution of the aforementioned code:

This code is executed when processing the Scan exec function in DocumentRetriever.ts when the library maps every Item returned by DynamoDB to their internal Document representation, in this line of code:

const array: any = (await Promise.all(result.Items.map(async (item) => await new this.internalSettings.model.Document(item, {"type": "fromDynamo"}).conformToSchema({"customTypesDynamo": true, "checkExpiredItem": true, "saveUnknown": true, "modifiers": ["get"], "type": "fromDynamo"})))).filter((a) => Boolean(a));

The reported error is a consequence of that change when the type of the returned Item is checked against the schema model in the checkTypeFunction:

const {isValidType, matchedTypeDetails, typeDetailsArray} = utils.dynamoose.getValueTypeCheckResult(schema, value, genericKey, settings, {"standardKey": true, typeIndexOptionMap});
if (!isValidType) {
  throw new Error.TypeMismatch(`Expected ${key} to be of type ${typeDetailsArray.map((detail) => detail.dynamicName ? detail.dynamicName() : detail.name.toLowerCase()).join(", ")}, instead found type ${typeof value}.`);
...

I do not see a clear solution, as I assume this property is heavily used in the context of the Document and the library itself. Of course, I think that every possibility pass to give this property a name that minimize the probability of collision with an attribute name, perhaps including some kind of character ($) not allowed by the DynamoDB naming rules.

[github-actions]

This issue is stale because it has been open 7 days with no activity. Remove stale label or comment or this will be closed in 3 days.

[jccampanero]

Any feedback on that topic? Please, can I help you in any way?

[fishcharlie]

@jccampanero No updates on this. As I said above, I don't see this being addressed anytime soon. If you want, feel free to work towards creating a PR. But I'm not sure I'll be able to find time to look into this anytime soon.

[elliottkopp]

Also running into this issue. I've had to rename my column from model to modelName. It works, but it's not ideal since now I'm changing my schema to accommodate this bug.

Additionally, if I don't include model in the schema itself but set saveUnknown to true and then set document.model = "string" and save the docuent, dynamoose writes a huge object out in the model field instead of the string which is not good.

Would love to see this addressed in a future version! Thanks!

[jccampanero]

I am very happy to see that the issue is solved in the new version of the library @fishcharlie.

I am sorry for hadn't been of more help in the resolution of the issue.

Please, don't hesitate to contact me if you think I could contribute to the project in some way, I will be glad to help.

[fishcharlie]

@jccampanero Testing v3 alpha versions (and hopefully soon beta) versions and providing feedback (positive or negative) would be incredibly helpful at this point 😃

[jccampanero]

Sure @fishcharlie, I will try testing the new version.

[nimit2801]

@jccampanero is it working for you?

Sure @fishcharlie, I will try testing the new version.

[jccampanero]

@nimit2801 I am very sorry to say, but honestly I haven't tested the new functionally yet.

May I ask why? Does the problem also occur in the new version of the library?

[nimit2801]

@nimit2801 I am very sorry to say, but honestly I haven't tested the new functionally yet.

May I ask why? Does the problem also occur in the new version of the library?

I'm actually using $ADD from the Docs to add String Set
And while I'm trying to pass Array or String, it throw a TypeMismatch: Expected likedMe to be of type string set, instead found type object.
Reference to discussion opened #1512