hardyscc / nestjs-dynamoose Goto Github PK

catModel.create(cat, { overwrite: true } ); -> Complains that it requires return

I'm submitting a bug

[ ] Regression 
[ x] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

A dependency from the Nest Dependency Injection tree, is not being injected in the DynamooseOptionsFactory when using useClass in a DynamooseModule.forRootAsync:

The DynamoDBConfigService:

import { ConfigService } from '@nestjs/config'
import { DynamooseModuleOptions, DynamooseOptionsFactory } from 'nestjs-dynamoose'

export class DynamoDBConfigService implements DynamooseOptionsFactory {
  
  constructor(private readonly configService: ConfigService){
    console.log({ configService }) // this should resolve to the correct instance
  }

  createDynamooseOptions(): DynamooseModuleOptions | Promise<DynamooseModuleOptions> {
    return {
      ...this.configService.get('dynamo.isLocal') ? ({ 
        local: 'http://dynamodb:8000',
        table: {
          create: true,
        },
      }) : {},
    }
  }
  
}

The app-module:

import { Module } from '@nestjs/common'
import { ConfigModule, ConfigService } from '@nestjs/config'
import {DynamoDBConfigService} from './DynamoDBConfigService'
import {DynamooseModule} from 'nestjs-dynamoose'
@Module({
  imports: [
    ConfigModule,
    DynamooseModule.forRootAsync({
      useClass: DynamoDBConfigService,
    }),
  ],
})
export class AppModule {}

Expected behavior

Injecting the ConfigService like so, was expected to work.

Minimal reproduction of the problem with instructions

https://github.com/rjpkuyper/nestjs-dynamoose-issue

What is the motivation / use case for changing the behavior?

For consistency, I expected that using forRootAsync would resolve the Nest dependency tree.

Environment

NestJS version: 9.1.2
NestJS Dynamoose version: 0.5.1
Dynamoose version: 3.1.0
 
For Tooling issues:
- Node version: 18
- Platform:  Mac, Linux

export interface AsyncModelFactory extends Pick<ModuleMetadata, 'imports'>, Pick<ModelDefinition, 'name' | 'options' | 'serializers'> {
    useFactory: (...args: any[]) => ModelDefinition['schema'] | Promise<ModelDefinition['schema']>;
    inject?: any[];
}

the AsyncModelFactory should not have the name property, the name, options, serializers should be return from useFactory rather than define in AsyncModelFactory.

For example, if I am going to inject some values from config, there is no way to access to it outside useFactory function.

I'm trying make a POST on Users route and the repository throws the following error. I don't know what to do more.

Error:
EndpointError: Endpoint URL must be a string, got object
    at getEndpointUrl (/home/lipe/toro/poc-boilerplate-toro-serverless/node_modules/@aws-sdk/util-endpoints/dist-cjs/utils/getEndpointUrl.js:17:11)
    at evaluateEndpointRule (/home/lipe/toro/poc-boilerplate-toro-serverless/node_modules/@aws-sdk/util-endpoints/dist-cjs/utils/evaluateEndpointRule.js:26:50)
    at evaluateRules (/home/lipe/toro/poc-boilerplate-toro-serverless/node_modules/@aws-sdk/util-endpoints/dist-cjs/utils/evaluateRules.js:11:89)
    at evaluateTreeRule (/home/lipe/toro/poc-boilerplate-toro-serverless/node_modules/@aws-sdk/util-endpoints/dist-cjs/utils/evaluateTreeRule.js:12:46)
    at evaluateRules (/home/lipe/toro/poc-boilerplate-toro-serverless/node_modules/@aws-sdk/util-endpoints/dist-cjs/utils/evaluateRules.js:20:81)
    at evaluateTreeRule (/home/lipe/toro/poc-boilerplate-toro-serverless/node_modules/@aws-sdk/util-endpoints/dist-cjs/utils/evaluateTreeRule.js:12:46)
    at evaluateRules (/home/lipe/toro/poc-boilerplate-toro-serverless/node_modules/@aws-sdk/util-endpoints/dist-cjs/utils/evaluateRules.js:20:81)
    at evaluateTreeRule (/home/lipe/toro/poc-boilerplate-toro-serverless/node_modules/@aws-sdk/util-endpoints/dist-cjs/utils/evaluateTreeRule.js:12:46)
    at evaluateRules (/home/lipe/toro/poc-boilerplate-toro-serverless/node_modules/@aws-sdk/util-endpoints/dist-cjs/utils/evaluateRules.js:20:81)
    at resolveEndpoint (/home/lipe/toro/poc-boilerplate-toro-serverless/node_modules/@aws-sdk/util-endpoints/dist-cjs/resolveEndpoint.js:26:48)

Repository: https://github.com/luizgomesdev/nestjs-dynamoose-serverless

NestJS version: 16.15.1
NestJS Dynamoose version: 0.5.0
Dynamoose version: 3.1.0

NestJS 10 allows reflect-metadata ^0.1.12 || ^0.2.0 but this module only allows 0.1.14 which results in an error:

npm ERR! Found: [email protected]
npm ERR! node_modules/reflect-metadata
npm ERR!   reflect-metadata@"^0.2.0" from the root project
npm ERR!   peer reflect-metadata@"^0.1.12 || ^0.2.0" from @nestjs/[email protected]
npm ERR!   node_modules/@nestjs/common
npm ERR!     @nestjs/common@"^10.3.3" from the root project
npm ERR!     peer @nestjs/common@"^6.0.0 || ^7.0.0 || ^8.0.0 || ^9.0.0 || ^10.0.0" from [email protected]
npm ERR!     node_modules/nestjs-dynamoose
npm ERR!       nestjs-dynamoose@"^0.5.7" from the root project
npm ERR!     5 more (@nestjs/core, @nestjs/microservices, ...)
npm ERR!   3 more (@nestjs/core, @nestjs/microservices, @nestjs/websockets)
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! peer reflect-metadata@"^0.1.12" from [email protected]
npm ERR! node_modules/nestjs-dynamoose
npm ERR!   nestjs-dynamoose@"^0.5.7" from the root project

I'm submitting a feature request

[ ] Regression 
[ ] Bug report
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

Dynamoose version 2.8.3 supports declaring schema with multiple type of attributes like the following
{ "editorId": [Number, String] }
When I try the same with the current version of nestjs-dynamoose it returns me with the following error:

TypeError: Cannot read properties of undefined (reading 'schema')
    at result.split.reduce.schema (/app/node_modules/dynamoose/lib/Schema.ts:795:34)
    at Array.reduce ()
    at Schema.getAttributeValue (/app/node_modules/dynamoose/lib/Schema.ts:785:87)
    at Schema.getAttributeSettingValue (/app/node_modules/dynamoose/lib/Schema.ts:408:31)
    at Schema.defaultCheck (/app/node_modules/dynamoose/lib/Schema.ts:386:39)
    at /app/node_modules/dynamoose/lib/Document.ts:362:39
    at Array.map ()
    at Function.Document.objectFromSchema (/app/node_modules/dynamoose/lib/Document.ts:357:80)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at Document.toDynamo (/app/node_modules/dynamoose/lib/Document.ts:513:17)

I believe the reason for this is because dependency 'dynamoose' version in nestjs-dynamoose is still in 2.2.0

My insertion follows batchPut command on the model.

Expected behavior

We should be able to use multiple type definition for the schema and be able insert data items without any errors.

Minimal reproduction of the problem with instructions

Declare a schema with multiple attribute types. Try batchPut operation on that model with any of the attribute types declared. The code fails

const model = new Schema({
    id: String,
    editorId: [Number, String]
};

// In controller/repository
const result = await this.model.batchPut([
    {"id": "1", "editorId": "1"},
    {"id": "2", "editorId": 2},
};
console.log(result);

What is the motivation / use case for changing the behavior?

It's easy when we are using a huge set of entities in a single table design and some attributes may need to support multiple types for different entities.

Environment

NestJS version: 8.1.4
NestJS Dynamoose version: 0.3.3
Dynamoose version: 2.8.3
 
For Tooling issues:
- Node version: 16.11.1
- Platform: Linux (Docker container)

How can we configure this to use DAX Client ? https://aws.amazon.com/dynamodb/dax/

https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/clients/client-dax/index.html

I'm submitting a...

[X] Bug report

Current behavior

Throwing the exception: hashKey must be at root object and not nested in object or array.

Expected behavior

The code is working properly when I use the synchronous method to feature a schema as below:

DynamooseModule.forFeature([
  { name: 'QA.B_BUREAU', schema: BureauSchema },
]),

Minimal reproduction of the problem with instructions

import { Module } from '@nestjs/common';
import { ConfigModule, ConfigService } from '@nestjs/config';
import { DynamooseModule } from 'nestjs-dynamoose';
import { BureauController } from './bureau.controller';
import { BureauSchema, dummySchema } from './bureau.schema';
import { BureauService } from './bureau.service';

@Module({
  imports: [
    DynamooseModule.forRootAsync({
      imports: [ConfigModule],
      useFactory: async (configSvc: ConfigService) => ({
        aws: {
          accessKeyId: configSvc.get('aws.dynamo.accessKeyId'),
          secretAccessKey: configSvc.get('aws.dynamo.secretAccessKey'),
          region: configSvc.get('aws.region')
        }
      }),
      inject: [ConfigService]
    }),
    DynamooseModule.forFeatureAsync([{
      imports: [ConfigModule],
      name: 'QA.B_BUREAU',
      useFactory: (configSvc: ConfigService) => ({
        name: 'QA.B_BUREAU',
        schema: BureauSchema,
      }),
      inject: [ConfigService],
    }])
  ],
  providers: [BureauService],
  controllers: [BureauController]
})
export class BureauModule {}

What is the motivation / use case for changing the behavior?

exception: hashKey must be at root object and not nested in object or array.

Environment

NestJS version: 8.1.1
NestJS Dynamoose version: 0.3.3
Dynamoose version: 2.8.2

 
For Tooling issues:
- Node version: 14.15.3
- Platform:  Mac, Linux

I'm submitting a...

[ ] Regression 
[x] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

nestjs-dynamoose v0.3.4, as published to NPM, supports NestJS v8.x but does not support v9.x
When utilizeing nestjs-dynamoose with NestJS v9+ there is a dependency conflict:

npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR! 
npm ERR! While resolving: [email protected]
npm ERR! Found: @nestjs/[email protected]
npm ERR! node_modules/@nestjs/common
npm ERR!   @nestjs/common@"^9.0.2" from the root project
npm ERR!   peer @nestjs/common@"^7.0.0 || ^8.0.0 || ^9.0.0" from @nestjs/[email protected]
npm ERR!   node_modules/@nestjs/config
npm ERR!     @nestjs/config@"^2.2.0" from the root project
npm ERR!   10 more (@nestjs/core, @nestjs/jwt, @nestjs/mapped-types, ...)
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! peer @nestjs/common@"^6.0.0 || ^7.0.0 || ^8.0.0" from [email protected]
npm ERR! node_modules/nestjs-dynamoose
npm ERR!   nestjs-dynamoose@"^0.3.4" from the root project
npm ERR! 
npm ERR! Conflicting peer dependency: @nestjs/[email protected]
npm ERR! node_modules/@nestjs/common
npm ERR!   peer @nestjs/common@"^6.0.0 || ^7.0.0 || ^8.0.0" from [email protected]
npm ERR!   node_modules/nestjs-dynamoose
npm ERR!     nestjs-dynamoose@"^0.3.4" from the root project

It appears this issue has been resolved in this repository by renovatebot (a76d3d0) and only needs to be deployed to NPM.

Adding the nestjs-dynamoose reference pointing to the above renovatebot commit as follows resolves the issue:
"nestjs-dynamoose": "hardyscc/nestjs-dynamoose.git#a76d3d0c38e385f6237f08392f19757ae0fb4390"

Expected behavior

Adding nestjs-dynamoose to any NestJS v9+ application should not result in dependency conflicts with the NestJS framework core libraries.

Minimal reproduction of the problem with instructions

Using any NestJS v9+ application, add a reference to nestjs-dynamoose by running npm install nestjs-dynamoose and then run npm ci.

What is the motivation / use case for changing the behavior?

I would like to build my application using NestJS v9, in order to resolve numerous downstream dependency vulnerabilities from NestJS v8, and to also use the nestjs-dyanmoose library in my NestJS v9 application.

Environment

NestJS version: 9.0.2
NestJS Dynamoose version: 0.3.4
Dynamoose version: 2.8.5

For Tooling issues:
- Node version: 18.0.0 
- Platform:  All

Others:

I used your module connect to dynamoDb. It worked very good.
But now i wanna write unit.

But there were some problem
my unit test file

describe('MissionService', () => {
  let service: MissionService;

  beforeEach(async () => {
    const module: TestingModule = await Test.createTestingModule({
      imports: [DynamooseModule.forFeature([MissionModel])],
      providers: [MissionService],
    }).compile();

    service = module.get<MissionService>(MissionService);
  });

  it('should be defined', () => {
    expect(service).toBeDefined();
  });
});

here is my module

@Module({
  imports: [DynamooseModule.forFeature([MissionModel])],
  controllers: [MissionControllerAdmin],
  providers: [MissionService, MissionRepository],
  exports: [MissionService, MissionRepository],
})
export class MissionModule {}

[ ] Regression 
[ ] Bug report
[ ] Feature request
[ ] Documentation issue or request
[X] Support request => [my post in stackoverflow.](https://stackoverflow.com/questions/77277788/config-unit-test-with-dynamoose-nestjs-jest)

NestJS version: 9.0.0
NestJS Dynamoose version: i moved your source code into my project in 3 month ago
Dynamoose version: 3.2.0

See: https://dynamoosejs.com/guide/Model#modelgetkey-settings

I'm submitting a...

[ ] Regression 
[ V] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

It seems that when using the serverless offline plugin with DynamooseModuleOptions, the aws.accessKeyId and aws.secretAccessKey default to the AWS credentials defaults. In my case, I use multiple AWS accounts and always used the --aws-profile option with sls. However, it seems that this option does not apply to DynamooseModuleOptions.

As a result, when connecting to AWS DynamoDB, it attempts to connect to the DynamoDB of a different account, causing an issue where it cannot find the table. In reality, when communicating with AWS DynamoDB in Lambda, these credentials are not necessary after deployment. However, when using multi-profiles with sls offline for testing, such issues seem to arise.

Expected behavior

It would be beneficial if the --aws-profile option could also be applied to DynamooseModuleOptionswhen testing with sls offline.

I'm submitting a...

[ ] Regression 
[ ] Bug report
[*] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

if a resource is not found, the get method only returns an empty object. it requires further check to throw the 404 error.

// users.service.ts
  async findOne(id: string) {
    const res = await this.users.get({id});
    if (!res) {
      throw new NotFoundException();
    }
    return res;
  }

Expected behavior

throw the built-in NotFoundException when the resource is not found. so the above code can be written as

// users.service.ts
  findOne(id: string) {
    return this.users.get({id});
  }

What is the motivation / use case for changing the behavior?

throw 404 when a resource is not found is a standard RESTful API behavior.

Environment

NestJS version: ^9.4.2
NestJS Dynamoose version: ^0.5.4
Dynamoose version: ^3.2.0

 
For Tooling issues:
- Node version: v18.16.0
- Platform:  Linux

Hey, great work! Maybe if you have time you could add a little more documentation? On the other hand I can find the most things in the interfaces and the dynamoose documentation so it might be okay.

Anyway, the first thing I would need is the dynamoose.local(); option. I dont see it in the DynamooseModuleOptions interface. And what about other functions like setDDB? Would be nice to have it in the DynamooseModuleOptions or no?

Documentation: https://dynamoosejs.com/api/config/#dynamoose-object

I'm submitting a...

[v] Bug report

Current behavior

When using the TransactionSupport feature of nestjs-dynamoose, an error occurs stating

Table 'XXX-YYY-ZZZ' not found. Please register the table with dynamoose before using it in transactions.

Expected behavior

The TransactionSupport feature should work as expected and recognize the table with prefixes (XXX-) and suffixes (-YYY).

Minimal reproduction of the problem with instructions

The error can be reproduced with the following configuration:

1. Set up DynamooseModule with prefix and suffix:

DynamooseModule.forRootAsync({
      imports: [ConfigModule],
      inject: [ConfigService],
      useFactory: async (configService: ConfigService) => {
        return {
          ...
          table: {
            prefix: 'XXX-',
            suffix: `-ZZZ`,
            ...
          },
        };
      },
    })

2. Define table schemas using DynamooseModule.forFeatureAsync:

DynamooseModule.forFeatureAsync([
      {
        name: 'Scoreboard',
        useFactory: async () => ({
          schema: ScoreboardSchema,
          options: { tableName: 'YYY' },
        }),
      },
      {
        name: 'ScoreboardInfo',
        useFactory: async () => ({
          schema: ScoreboardInfoSchema,
          options: { tableName: 'YYY' },
        }),
      },
      {
        name: 'User',
        useFactory: async () => ({
          schema: UserSchema,
          options: { tableName: 'YYY' },
        }),
      },
    ])

3. Use TransactionSupport:

await this.transaction([ ... ])

And the error message is printed like

Table "XXX-YYY-ZZZ" not found. Please register the table with dynamoose before using it in transactions.

4. This issue does not seem to occur when manually setting the table name with prefix and suffix included:

{
  name: 'User',
  useFactory: async () => ({
    schema: UserSchema,
    options: { tableName: 'XXX-YYY-ZZZ' },
  }),
}

What is the motivation / use case for changing the behavior?

The current implementation of TransactionSupport does not appear to correctly handle table prefixes and suffixes, which leads to inability to find the table when using transactions.

Environment

NestJS version: ^9.0.0
NestJS Dynamoose version: 0.5.5
Dynamoose version: 3.2.0

 
For Tooling issues:
- Node version: 18.16.0  
- Platform: MacOS  

Others:

see https://dynamoosejs.com/guide/Model/#modelbatchgetkeys-settings

Model.get(key, settings?, cb?) now accepts an array of attributes in the settings:
https://dynamoosejs.com/guide/Model#modelgetkey-settings

And maybe other changes, see: https://github.com/dynamoose/dynamoose/releases

This brings me back to #76 :)

Hey there,

I need to be able to use model document functions as documented here: https://dynamoosejs.com/guide/Model/#modelmethodsdocumentsetname-function

is there a way of doing it using this?

PS: Thanks for this great library!

I'm submitting a...

[ ] Regression 
[x] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

After updating to dynamoose latest version v4.0.0, the following error is shown on npm install:

npm ERR! While resolving: [email protected]
npm ERR! Found: [email protected]
npm ERR! node_modules/dynamoose
npm ERR!   dynamoose@"^4.0.0" from the root project
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! peer dynamoose@"^3.2.0" from [email protected]
npm ERR! node_modules/nestjs-dynamoose
npm ERR!   nestjs-dynamoose@"^0.5.5" from the root project
npm ERR! 
npm ERR! Conflicting peer dependency: [email protected]
npm ERR! node_modules/dynamoose
npm ERR!   peer dynamoose@"^3.2.0" from [email protected]
npm ERR!   node_modules/nestjs-dynamoose
npm ERR!     nestjs-dynamoose@"^0.5.5" from the root project

Expected behavior

Should work with dynamoose v4.0.0.

Minimal reproduction of the problem with instructions

Update dynamoose to v.4.0.0 and run npm install.

What is the motivation / use case for changing the behavior?

Supported new dynamoose version.

Environment

NestJS version: 20.10
NestJS Dynamoose version: 0.5.5
Dynamoose version: 4.0.0

I'm submitting a...

[ ] Regression 
[ ] Bug report
[X] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

As of dynamoose v2.3.0, Dynamoose now supports using multiple Schemas per table. Need to change the ModelDefinition interface to reflect this.

Expected behavior

ModelDefinition would be able to support a single Schema object or an array of Schema objects.

Minimal reproduction of the problem with instructions

Create multiple schemas for a Model. Try to add them to a module via
DynamooseModule.forFeature([{ name: 'Bar', schema: [BarSchema, BarBazSchema] }])

What is the motivation / use case for changing the behavior?

See above. :)

Environment

Nest version: X.Y.Z

 N/A
For Tooling issues:
- Node version: XX  
any
- Platform:  
any

Others:

`dynamoose` v.2.3.0

Add transaction

I'm submitting a...

[ ] Regression 
[x] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

feat: move tableName from model to options

This is a breaking change and requires proper versioning.

Expected behavior

I was running into a simple problem with aws serverless and needed to dump node_modules and hit npm install afterwards.
Because of the config change, all my table names defaulted to model names.
When the models start running on production it re-created all tables because the table names mismatched.

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Environment

NestJS version: X.Y.Z
NestJS Dynamoose version: X.Y.Z
Dynamoose version: X.Y.Z

 
For Tooling issues:
- Node version: XX  
- Platform:  

Others:

I'm submitting a consideration for a feature request i'm working in: in module options, allow the user to pass a custom ddb instance to set in dynamoose.

[ ] Regression 
[ ] Bug report
[x ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

Currently user can pass as model options the following: aws, local, model, logger. My proposal is to include a custom ddb config

Expected behavior

Allow the user to pass a custom dynamoose ddb without alter the actual lib behavior.

Minimal reproduction of the problem with instructions

I'm working on this in a forked repo so i can submit the pull request to be evaluated

What is the motivation / use case for changing the behavior?

Passing a custom ddb instance can ease the custom dynamoose needs (for example mocking the dynamoose instance for testing purposes), but posibilities increases a lot.

Environment

NestJS version: 6.0.0+
NestJS Dynamoose version: 0.3.3
Dynamoose version: 2.8.5

 
For Tooling issues:
- Node version: XX  
- Platform:  

Others:

I'm submitting a...

[ ] Regression 
[ ] Bug report
[X] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

In the example the model is used within a sub-module. But if I want to use the model in the app module, should i import DynamooseModule.forRoot AND DynamooseModule.forFeature?

Does it make sense to be able to add the models to forRoot, too?

I'm submitting a...

[ ] Regression 
[ ] Bug report
[X] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

I am interested in trying out the dynamoose v3 beta with nestjs. Is there any plan to provide a version of this plugin that works with the v3 beta? Alternatively, what changes would be needed to get this plugin to work with newer version of dynamoose? Thanks!

Currently, I get this error when using dynamoose v3.0.0-beta.2 with nestjs-dynamoose 0.3.2:

Type '{ type: StringConstructor; index: { name: string; rangeKey: string; global: true; throughput: "ON_DEMAND"; }[]; }' is not assignable to type 'AttributeType | AttributeType[] | AttributeDefinition | AttributeDefinition[]'.
  Types of property 'index' are incompatible.
    Type '{ name: string; rangeKey: string; global: true; throughput: "ON_DEMAND"; }[]' is not assignable to type 'boolean | IndexDefinition | IndexDefinition[]'.
      Type '{ name: string; rangeKey: string; global: true; throughput: "ON_DEMAND"; }[]' is not assignable to type 'IndexDefinition[]'.
        Type '{ name: string; rangeKey: string; global: true; throughput: "ON_DEMAND"; }' is not assignable to type 'IndexDefinition'.
          Object literal may only specify known properties, and 'global' does not exist in type 'IndexDefinition'.

19           global: true,
             ~~~~~~~~~~~~

  node_modules/dynamoose/dist/Schema.d.ts:586:5
    586     [attribute: string]: AttributeType | AttributeType[] | AttributeDefinition | AttributeDefinition[];
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    The expected type comes from this index signature.

I'm submitting a...

[ ] Regression 
[ ] Bug report
[X] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

I couldn't find any way of adding a logger or loggers via DynamooseModule.forRoot. Is there another way of accessing the underlying dynamoose object so this can be done?

Expected behavior

Should have the ability to set a logger or loggers via configuration object, or via code.

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

I'd like to see the queries being executed under the hood.

Environment

Nest version: 7.4.0

 
For Tooling issues:
- Node version: XX  
- Platform:  

Others:

In line 70 of dynamoose-core.module.ts

it looks like the DYNAMOOSE_MODULE_OPTIONS has never been used as a provide token to inject anything.

Is it necessary here?

Iḿ submitting a bug

[ ] Regression 
[x] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

Currently when trying to connect with DynamoDB from an EC2 instance, with IAM role assigned nestjs-dynamoose still cant connect with DynamoDB. However, there already is support for this feature in the official Dynamoose documentation and it seems that currently passing accesstokens should be optional (and thus support IAM roles):

export interface DynamooseModuleOptions {
  aws?: {
    accessKeyId?: string;
    secretAccessKey?: string;
    region?: string;
  };
  local?: boolean | string;
  model?: ModelOptionsOptional;
  logger?: boolean | LoggerService;
}

However, even when leaving this empty, and assigning IAM roles to the EC2 instance, we cannot connect with DynamoDB.

Expected behavior

IAM roles on an instance should always be taken into consideration when trying to connect with DynamoDB.

Environment

[email protected]
[email protected]

I'm submitting a...

[ ] Regression 
[ ] Bug report
[X] Feature request
[X] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

I am unable to dynamically define the DynamoDB table name for any specific DynamooseModule.forFeature using the NestJS ConfigService.

The DynamooseModule.forFeatureAsync implementation does not have any supporting documentation and appears to only be able to utilize the injected dependencies to define schema properties and values, and not the name of the table.

Expected behavior

I would like to be able to use an injected ConfigService when referring to DynamooseModule.forFeatureAsync to load the table name from my NestJS configuration provider.

Minimal reproduction of the problem with instructions

There's no reproduction of any defect, only the inability to access NestJS ConfigService from within the scope of defining a table name.

What is the motivation / use case for changing the behavior?

I would like to be able to set the following Platform string value from the NestJS ConfigService like so:

DynamooseModule.forFeature([
			{
				name: 'Platform', // Get this value from configService.get('DYNAMO.TABLES.PLATFORM_TABLE_NAME')
				schema: PlatformSchema,
			},
		]),
	],

This is necessary because AWS DynamoDB does not support restore-in-place, therefore when restoring a backup we must restore to a new table name, and we would like the ability to define our dynamodb table names in our NestJS configuration provider.

Environment

NestJS version: 9.0.2
NestJS Dynamoose version: 0.4.0
Dynamoose version: 2.8.5

 
For Tooling issues:
- Node version: 16.16.0  
- Platform:  Mac 

Others:

I'm submitting a...

[ ] Regression 
[ ] Bug report
[x] Feature request
[ ] Documentation issue or request

Current behavior

Dynamoose supports adding custom serializers, like so:

User.serializer.add("myCustomSerializer", {
	include: ["email"]
});

...

myUser.serialize("myCustomSerializer");

However, there are no type definitions for serializers in nestjs-dynamoose

Expected behavior

I think something like this might be a good way to define serializers in NestJS:

DynamooseModule.forFeature([{
	name: 'User',
	schema: UserSchema,
	serializers: {
		"myCustomSerializer": { include: ["email"] },
	},
}])

...

myUser.serialize("myCustomSerializer");

Alternatively, forFeature might accept an already-defined Model, which could have serializers defined before being passed in the import.

I'm submitting a...

[ ] Regression 
[ ] Bug report
[ ] Feature request
[x] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

The problem occurs when trying to log in after the IAM role assigned to the deployment in K8S. Problem when attempting to connect. Pod in kubernetes sees the variables assigned by the IAM roles ie. AWS_ROLE_ARN, AWS_WEB_IDENTITY_TOKEN_FILE, AWS_DEFAULT_REGION, AWS_REGION.

Error code

After running npm run start:prod

/app/node_modules/aws-sdk/lib/http/node.js:69
              new Error('Socket timed out without establishing a connection'),
              ^
CredentialsError: Missing credentials in config, if using AWS_CONFIG_FILE, set AWS_SDK_LOAD_CONFIG=1
    at Timeout.connectTimeout [as _onTimeout] (/app/node_modules/aws-sdk/lib/http/node.js:69:15)
    at listOnTimeout (node:internal/timers:559:17)
    at processTimers (node:internal/timers:502:7)

app.module.ts file

const isProduction = process.env.NODE_ENV === 'production';
const dynamooseConfig = isProduction
  ? { model: { prefix: 'myprefix' } }
  : { local: 'http://dynamodb:8000/', model: { prefix: 'myprefix' } };

console.log('isProduction: ', isProduction);
console.log(
  process.env.AWS_ROLE_ARN,
  process.env.AWS_SES_ENDPOINT,
  process.env.AWS_WEB_IDENTITY_TOKEN_FILE,
  process.env.AWS_DYNAMODB_ENDPOINT,
  process.env.AWS_ROLE_SESSION_NAME,
  process.env.AWS_SDK_LOAD_CONFIG,
  process.env.AWS_DEFAULT_REGION,
  process.env.AWS_REGION,
);

@Module({
  imports: [
    DynamooseModule.forRoot(dynamooseConfig),
    ConfigModule.forRoot(),
    AuthzModule,
    UsersModule,
    TrackingModule,
    SyncFuelPriceModule,
    TotalPriceModule,
    QuoteModule,
    UpdateQuoteStatusModule,
  ],
  controllers: [AppController],
  providers: [AppService, MailerService],
})
export class AppModule {}

When script is executed app corectly see env variables assigend by default IAM Role.

DynamoDB

Official DynamoDB says that "If you are running Dynamoose in an environment that has an IAM role attached to it (ex. Lambda or EC2), you do not need to do any additional configuration so long as your IAM role has appropriate permissions to access DynamoDB"
https://dynamoosejs.com/getting_started/Configure/#iam-role

Dependencies:

"@aws-sdk/client-ses": "^3.100.0",
"@aws-sdk/credential-provider-node": "^3.100.0",
"@aws-sdk/client-ses": "^3.100.0",
"@aws-sdk/credential-provider-node": "^3.100.0",
"@nestjs/common": "^8.0.0",
"@nestjs/config": "^2.0.0",
"@nestjs/core": "^8.0.0",
"@nestjs/mongoose": "^9.0.3",
"@nestjs/passport": "^8.2.2",
"@nestjs/platform-express": "^8.0.0",
"axios": "^0.27.2",
"class-transformer": "^0.5.1",
"class-validator": "^0.13.2",
"dynamoose": "^2.8.5",
"jwks-rsa": "^2.1.4",
"nestjs-dynamoose": "^0.3.4",
"nodemailer": "^6.7.5",
"passport": "^0.6.0",
"passport-jwt": "^4.0.0",
"reflect-metadata": "^0.1.13",
"rimraf": "^3.0.2",
"rxjs": "^7.2.0",
"superagent": "^8.0.0",
"ts-results": "^3.3.0",
"uuid": "^8.3.2",
"mjml": "^4.13.0",
"nanoid": "3.3.4"

•  Image based on node:16.16.0-alpine
  

I'm submitting a...

[ ] Regression 
[ ] Bug report
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

A dynamoose model can have a default field value provided in the schema definition. With original dynamoose types, when a new model instance is created using Model.create it's not required to provide a value for these fields. With model definition from this library all fields that are required in the model interface are also required while creating a model instance. This makes it impossible to use a default value from the schema definition.

As a workaround, fields with a default value can be marked as optional. However this isn't really correct as these values will be filled in by dynamoose and when the model instance is retrieved they are expected to not be empty.

Expected behavior

Model.create argument should at least be defined as Partial of the model type. Alternatively, a model interface could accept a third (optional) generic argument with a list of fields that are not mandatory. I'm using the latter approach with my own type definitions for first version of a dynamoose and it looks more or less like this:

type FooKey = { id: string }
type Foo = FooKey & { bar: string, baz: number }
type DefaultFields = 'id' | 'baz';

export type FooModel = Model<Foo, FooKey, DefaultFields>;

export const FooSchema = new Schema({
  id: {
    type: String,
    hashKey: true,
    default: uuid,
  },
  bar: {
    type: String,
    required: true,
  },
  baz: {
    type: Number,
    required: true,
    default: 0,
  },
});

Minimal reproduction of the problem with instructions

export class FooService {
  constructor(
    @InjectModel('Foo')
    private fooModel: Model<Foo, FooKey>,
  ) {}

  create() {
    this.fooModel.create({ bar: 'bar' });  // this works correctly, but fails a compilation step
  }
}

What is the motivation / use case for changing the behavior?

In my opinion, a companion library like this should not prevent the usage of a feature from underlying library.

Environment

Nest version: 7.1.3

 
For Tooling issues:
- Node version: 12.16.3  
- Platform: Linux 

Others:

I'm submitting a new bug report

[ ] Regression 
[x] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

Model operations fails when you use the types Object or Array in schema definition, this can be solved by defining the useDocumentTypes schema property

Expected behavior

Model operations should work properly when using types Object or Array

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Environment

NestJS version: X.Y.Z
NestJS Dynamoose version: X.Y.Z
Dynamoose version: X.Y.Z

 
For Tooling issues:
- Node version: XX  
- Platform:  

Others:

Hello,

I'm trying to search with a range/sort key using the example boilerplate, but I keep getting "The provided key element does not match the schema".

Could you provide an example of how you would query with the following schema:

import { Schema } from 'dynamoose';

export const NotificationSchema = new Schema({
  id: {
    type: String,
    hashKey: true,
  },
  targetId: {
    type: String,
    index: {
      global: true,
      rangeKey: 'status',
    },
  },
  userId: {
    type: String,
    index: {
      global: true,
      rangeKey: 'status',
    },
  },
  content: {
    type: String,
  },
  status: {
    type: String,
  },
  createAt: {
    type: String,
    rangeKey: true,
  },
});

• createAt is the rangeKey.

• You import: import { Schema } from 'dynamoose'; but this does not exist?
• In the 4th step you inject constructor(@InjectModel('User') private userModel: Model<User>) {} but where is User coming from?
• In the 4th step you inject constructor(@InjectModel('User') private userModel: Model<User>) {} but Model<DataSchema, KeySchema> requires two type arguments

Btw. could you add to the readme, just a sentence, what is the benefit of using this module over "plain" Dynamoose? E.g. Dynamoose module for Nest. Use this to have dependency injection for your models. or something like that.

I saw you wrote typings for Model, Query, Scan, etc. thats awesome! Could you add the typings to the Dynamoose root project instead?

So the root project has a index.d.ts and can be used within TypeScript projects with autocompletion, that would be awesome! :)

Any option to support Web identity token credentials like it is mentioned here? https://npm.io/package/@aws-sdk/credential-provider-node. In such case such env variables are provided like AWS_WEB_IDENTITY_TOKEN_FILE, AWS_DEFAULT_REGION, AWS_REGION oraz AWS_ROLE_ARN and short lived tokens are used and automatically refreshed.
It is used often in EKS (AWS managed Kubernetes) and there is no need to exchange credentials like key id and secret key. So for container based apps it would be beneficial.

Hello,

I'm new to DybamoDB, so I imagine this is working as expected, but I'm getting a ResourceNotFoundException.

The table DOES NOT exist in DynamoDB, so this error is technically accurate, but I didn't think it would throw this error. Do tables have to exist in DynamoDB for this to work?

Thanks

The UpdateTransaction interface is type <Key, Data>

update: UpdateTransaction<Key, Data>;

this produce a error when typescript try to match the updateObj object as the keyObj
Overload 1 of 5, '(keyObj: DBProfileItem, updateObj: Partial<DBProfileKey>): UpdateTransactionResult', gave the following error. Argument of type 'DBProfileKey' is not assignable to parameter of type 'DBProfileItem'. Type 'DBProfileKey' is missing the following properties from type 'DBProfileItem': photo, email, firstName, lastName Overload 2 of 5, '(keyObj: DBProfileItem, updateObj?: Partial<DBProfileKey>, settings?: ModelUpdateSettings): UpdateTransactionResult', gave the following error. Argument of type 'DBProfileKey' is not assignable to parameter of type 'DBProfileItem'.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• chore(deps): update dependency reflect-metadata to v0.2.2
• chore(deps): update dependency @types/node to v20.12.2
• chore(deps): update typescript-eslint monorepo to v7.5.0 (@typescript-eslint/eslint-plugin, @typescript-eslint/parser)
• chore(deps): lock file maintenance

Pending Status Checks

These updates await pending status checks. To force their creation now, click the checkbox below.

• chore(deps): update dependency typescript to v5.4.4

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

the dependency need to be updated

└─┬ nestjs-dynamoose 0.5.4
  ├── ✕ unmet peer @nestjs/common@"^6.0.0 || ^7.0.0 || ^8.0.0 || ^9.0.0": found 10.0.1
  └── ✕ unmet peer @nestjs/core@"^6.0.0 || ^7.0.0 || ^8.0.0 || ^9.0.0": found 10.0.1

I'm submitting a...

[ ] Regression 
[ ] Bug report
[ ] Feature request
[x] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

Module configuration object seems to differ from dynamoose configuration object capabilities

Expected behavior

I would expect to be able to initiate the module with the same capabilities of dynamoose

Minimal reproduction of the problem with instructions

...
import { fromTokenFile } from '@aws-sdk/credential-providers';
...
DynamooseModule.forRoot({
      ddb: {
        config: {
          credentials: fromTokenFile(),
        },
      },
    }),

Throws TS error.

While

import * as dynamoose from 'dynamoose';
import { fromTokenFile } from '@aws-sdk/credential-providers';

const ddb = new dynamoose.aws.ddb.DynamoDB({
  credentials: fromTokenFile(),
});

Compiles correctly.

It would be awesome to be able to set the same through the module.

What is the motivation / use case for changing the behavior?

High chances that I'm doing it wrong.
I'm testing by hand how I can configure the module to use fromTokenFile which is a way to use env variables like

AWS_ROLE_ARN
AWS_WEB_IDENTITY_TOKEN_FILE

to connect to DynamoDB.

Environment

NestJS version: 9.2.1
NestJS Dynamoose version: 0.5.0
Dynamoose version: 3.1.0

 
For Tooling issues:
- Node version: 18.5.0  
- Platform: Mac 

Others:
`"@aws-sdk/credential-providers": "3.226.0"`

I'm submitting a new feature which can create migration for dynamodb.

right now i have to insert a data if i wanna create table.
Or may i missing it, can anyone help me to explain what i missed or i did wrong?

[X] Feature request

Environment

NestJS version: 10.1.10
NestJS Dynamoose version: 0.5.5
Dynamoose version: 3.2.0

 
For Tooling issues:
- Node version: v18.12.1 
- Platform:   Mac

I'm submitting a...

[X] Regression 
[ ] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

The Document => Item / DocumentRetrieverResponse => ItemRetrieverResponse changes introduced in v0.5.3 should be considered a breaking API change, so the version should have been set to 0.6.0 to avoid breaking consumers that depended on ^0.5.0.

As an alternative to maintain compatibility, the Document and DocumentRetrieverResponse interfaces could have been kept (ie interface Document extends Item... and interface DocumentRetrieverResponse extends ItemRetrieverResponse...).

Hello, I"m having trouble creating a schema that has a different model as a type for one of its properties. Similar to how it is documented here https://dynamoosejs.com/guide/Schema#model-types for the gameSchema

As far as I understand, I don't have access to the user model object that is being created when I pass the schema to DynamooseModule.forFeature()

Is there a way to do this currently? Thank you!

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: undefined. Note: this is a nested preset so please contact the preset author if you are unable to fix it yourself.

Could you please remove all interfaces related to Dynamoose?

It now has its own type definitions and it could happen that the IDE imports typings from nestjs-dynamoose by mistake and those type definitions are deprecated.

I have used: 0.2.0-beta.2

Also readme should be updated: Model should not be imported from nestjs-dynamoose but from dynamoose

I am very interested in your best practices in the use of nestjs-dynamoose. Especially in the context of the "single table" pattern. NestJs basically offers the concepts: Module, Controller, Service. If, for example, n different types of entities are stored in the "single table", I can split the NestJS modules as follows:

1-x Module -> n-x Controller -> n-x Service (per Model)

n-x Module -> 1-x Controller -> 1-x Service (per Model)

While the first approach seems very monolithic, the second is probably too fine-granular. But let's start with the "n-x Module" approach, i.e. one Module == one Document (aka Entity) Type:

FooModule.ts:

@Module({
  imports: [
    DynamooseModule.forFeature([{ name: 'single-table', schema: [ FooSchema ]}]),
  ]
  ...

BarModule.ts:

@Module({
  imports: [
    DynamooseModule.forFeature([{ name: 'single-table', schema: [ BarSchema ]}]),
  ]
  ...

This looks reasonable, at least as long the types of entities dont overlap functionality. If I really need functionality from another module, I simply import the related services as follows:

BazModule.ts:

@Module({
  imports: [
    DynamooseModule.forFeature([{ name: 'single-table', schema: [ BazSchema ]}]),
    FooService,
    BarService
  ]
  ...

But what if I need to utilize transactions? The exported services from other modules don't help here, because transactions are implemented on Model level not on Service level.

TransactionalBazModule.ts:

@Module({
  imports: [
    DynamooseModule.forFeature([{ name: 'single-table', schema: [ FooSchema, BarSchema, BazSchema ]}])
  ]
  ...

BazService.ts:

@Injectable()
export class BazService extends TransactionSupport {
  constructor(
    @InjectModel('single-table')
    private fooModel: Model<Foo, FooKey>,
    @InjectModel('single-table')
    private barModel: Model<Bar, BarKey>,
    @InjectModel('single-table')
    private bazModel: Model<Baz, BazKey>,
  ) {
    super();
  }

  async create(foo: Foo, bar: Bar, baz: Baz) {
    await this.transaction([
      this.fooModel.transaction.create(foo),
      this.barModel.transaction.create(bar),
      this.bazModel.transaction.create(baz),
    ]);
  }
}
...

Hey, could you release 0.2.0-beta to to latest in npm? So it is no more a beta?

Also feel free to join the Dynamoose Slack channel if you want :) https://join.slack.com/t/dynamoose/shared_invite/enQtODM4OTI0MTc1NDc3LWI3MmNhMThmNmJmZDk5MmUxOTZmMGEwNGQzNTRkMjhjZGJlNGM5M2JmZjMzMzlkODRhMGY3MTQ5YjQ2Nzg3YTY