arsenyyankovsky / nova-odm Goto Github PK

Hi !
First of all, thanks to migrate this project to aws-sdk v3, it works like a charm!

With Typescript 5, they release new decorators but they are not compatible with the old ones cf :
https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-0.html#differences-with-experimental-legacy-decorators

This new decorator's proposal is not compatible with --emitDecoratorMetadata

Do you plan to do a new version with Typescript 5 decorator so we can use them in our project?

Thanks

can i use this for single table design?

Hi,

I recently encountered perhaps a bit of a niche issue, which may only affect users that read from the DynamoDB via @nova-odm but write to it via the v3 DynamoDB document client, for example in order to do transactional writes, which aren't supported by @nova-odm, nor were supported by the v2 predecessor @aws/dynamodb-data-mapper.

For example in scenarios where someone is feeding data unmarshalled by @nova-odm into the official v3 DynamoDB document client, which then marshals it again for DynamoDB, one will end up with wrongly converted number values if these were unmarshalled to the type NumberValue.

So instead of:

{
  "id": { "S": "123" },
  "amount": { "N": "4000" }
}

one would end up with a record like this in the DynamoDB:

{
  "id": { "S": "123" },
  "amount": { "M": { "value": { "S": "4000" } } }
}

This cross-compatibility between the marshalling logic of the @aws/dynamodb-data-mapper and the aws-sdk (v2) used to work without problems, as NumberValue objects from the data mapper were correctly interpreted by the marshaller of the DynamoDB document client in the v2 SDK.

Working example in v2 ecoystem:

import { NumberValue } from "@aws/dynamodb-auto-marshaller";
import AWS from "aws-sdk";

const unmarshalledRecord = {
  id: "123",
  amount: new NumberValue("4000"),
};

const marshalledRecord = AWS.DynamoDB.Converter.marshall(unmarshalledRecord);
// { "id": { "S": "123" }, "amount": { "N": "4000" } }

Failing example in v3 ecosystem:

import { NumberValue } from "@nova-odm/auto-marshaller";
import { marshall } from "@aws-sdk/util-dynamodb";

const unmarshalledRecord = {
  id: "123",
  amount: new NumberValue("4000"),
};

// marshall(unmarshalledRecord);
// throws "Error: Unsupported type passed: 4000. Pass options.convertClassInstanceToMap=true to marshall typeof object as map attribute."
//
// as NumberValue instance cannot be mapped to any known type so is treated as random object
// which be default results in an error if the marshaller is not explicitly told to convert it to a map

const marshalledRecord = marshall(unmarshalledRecord, {
  convertClassInstanceToMap: true,
}); // {"id":{"S":"123"},"amount":{"M":{"value":{"S":"4000"}}}}

Possible Cause

After looking into the differences of the v2 and v3 marshalling logic, it seems that v3 previously established the type of a variable via a utility function typeOf (lib/dynamodb/types.js#L3) which is used before the conversion takes place (ib/dynamodb/converter.js#L29C1-L29C1) and which basically only really looks at the name of the constructor. So if two different classes have the same name, then they would be treated equally, i.e. in this case the NumberValue instance constructed by the @aws/dynamodb-data-mapper would be treated the same way as an instance of the NumberValue class defined in the v2 SDK (ib/dynamodb/numberValue.js#L11).

The new v3 SDK instead only performs an instanceof comparison (util-dynamodb/src/convertToAttr.ts#L41) against the NumberValue class defined in the @aws-sdk/util-dynamodb module (util-dynamodb/src/NumberValue.ts#L16). As @nova-odm's own NumberValue class does not inherit from that class though, the instanceof check fails and the NumberValue object is treated like a random class which depending on the marshaller configuration of the v3 SDK ends up being converted to a map instead.

Possible Solution

I'm not entirely sure what's the best way to reestablish this cross-compatibility, but perhaps the NumberValue implementation of @nova-odm could inherit from the v3 NumberValue definition as provided by the @aws-sdk/util-dynamodb module.

My personal workaround for the moment is to refrain from using the v3 document client and instead use the v3 generic DynamoDB client and marshal the records with the marshaller from @nova-odm.

Any thoughts or ideas?

Hi,

while attempting to include these libaries in a project with yarn2, the following error occurred:

➤ YN0000: ┌ Resolution step
➤ YN0002: │ @nova-odm/annotations@npm:0.8.7::__archiveUrl=[...]2Fnpm%2Fnpm%2F%40nova- \
odm%2Fannotations%2F-%2Fannotations-0.8.7.tgz doesn't provide @aws-sdk/client-dynamodb (p1924d), \
 requested by @nova-odm/auto-marshaller
[...]

Comparing the annotations package with the other ones, it seems the peer dependency to @aws-sdk/client-dynamodb is missing.

Best regards,
Alex

I just migrated from AWS SDK v2 to v3 and decided to use this as a replacement for dynamodb-data-mapper-js.

However I get the following error whenever I try to execute a ScanPaginator or QueryPaginator:
TypeError: Cannot read properties of undefined (reading '0').

A search on the internet has led me to this:
https://stackoverflow.com/questions/68820119/aws-aws-sdk-lib-dynamodb-cannot-read-property-0-of-undefined

Upon checking the sources of this repository I see that the ScanCommand and QueryCommand are indeed imported from @aws-sdk/client-dynamodb instead of @aws-sdk/lib-dynamodb.

My dependencies are:

    "@aws-sdk/client-dynamodb": "^3.462.0",
    "@aws-sdk/lib-dynamodb": "^3.462.0",
    "@nova-odm/query-iterator": "^0.8.7",