question: `update` an item map attributes instead of replacing the map

Summary:

I’m trying to implement a serverless framework/blueprint to integrate ORM, a RESTFul HTTP interface, enforce a lot of opinionated constrains to minimize discussion between team.

One of those constrains needed to integrate JSON-API (https://jsonapi.org) PATCH queries is that the updates have to be atomic, so if I send a patch with address: { postalCode: 1231 }, being address a map, it must not replace the entire map, but only update the nested postalCode.

The issue is that however I use .update, it overrides the entire map instead of replacing only the address.postalCode value.

Sorry if below I input only the object definitions instead of the full calls, it is since those are generated dynamically from those objects.

Code sample:

Schema

{
   id       : {
      type    : String,
      hashKey : true,
      readonly: true,
      default : () => {
        return uuid.v4();
      }
    },
    address  : {
      type: 'map',
      map : {
        streetAddress      : {
          type    : String,
          required: true
        },
        state              : {
          type    : String,
          required: true
        },
        country            : {
          type    : String,
          required: true
        },
        postalCode         : {
          type    : Number,
          required: true
        },
        postOfficeBoxNumber: {
          type: Number
        }
      }
    }
}

Model

It is dynamically generated from the above schema object. It is named “user”.

General

I’ve tried a lot of update calls:

this.update(key, {
   address: {
       postalCode: 2312
   }
});

this.update(key, {
    $PUT: {
        address: {
          postalCode: 2312
       }
   }
});

this.update(key, {
    $ADD: {
        address: {
          postalCode: 2312
       }
   }
});

but none of them works, $PUT replaces the entire map whereas $ADD throws an error saying that a MAP it is not a valid operator for $ADD.

Current output and behavior:

However I use .update, it overrides the entire address map instead of replacing only the address.postalCode value.

Expected output and behavior:

A way to only replace the address.postalCode nested map item.

Environment:

Operating System: Kubuntu Operating System Version: 18.04 Node.js version (node -v): v12.8.1 NPM version: (npm -v): 6.10.2 Dynamoose version: 1.10.0 Dynamoose Plugins: None

Dynamoose Plugins:

• Yes, I believe that one or multiple 3rd party Dynamoose plugins are effecting this issue
• No, I believe this issue is independent of any 3rd party Dynamoose plugins I’m using
• Unknown, I’m unsure if Dynamoose plugins are effecting this issue
• I am not using any Dynamoose plugins

Other information (if applicable):

Type (select 1):

• Bug report
• Feature suggestion
• Question
• Other suggestion
• Something not listed here

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 ensured that all of my plugins that I’m using with Dynamoose are listed above
• I have filled out all fields above
• I am running the latest version of Dynamoose

[hoangnguyenba]

Any update on this issue?

[fishcharlie]

@andrewda Couple of things:

1. It’s important to note that not all nested objects are schemas. I don’t think this will impact implementation based on how it’s setup. But is important to be aware of.
2. Also important to note that you can set the update object to be {"inner.prop1": "hello world"} and that will do the same as $SET.
3. I don’t think $DELETE is allowed in this case? Need to be sure we handle that edge case.
4. Finally. Concerned about that last example. Throughout Dynamoose currently we signify . as a nested property. Using [0] to signify that would be a change in the pattern of how we are currently doing things. I’m hesitant about diverging too much between internal patterns and external user facing API. I also forget, are brackets allowed as property names?? We don’t currently have a use case to prevent that, but DynamoDB itself might not allow them. If they do allow it, that might cause conflict with property names. I think my proposal here is to change it to be $REMOVE: ['inner.prop3.0']. What do you think?

Really want to have good tests around this. Ideally we’d cover all of the following:

• Nested Schemas
• Nested Objects (without separate schema)
• Nested Schemas within Arrays
• Nested Objects within Arrays
• $DELETE edge cases
• With $SET and without

It’d be great if we can figure out a good way to ensure that stays DRY. Our tests right now aren’t very DRY. At some point I wanna go back through and improve that. A lot of that can be done by nested it statements within forEach loops and such to spawn multiple the same test with slightly different variables.

That is all I can think about now. I like the proposal, and minus the things I said above, I think if you want, you can for sure take a shot at a PR for this. Thank you so much for your help here!!!