nestjs / azure-database Goto Github PK

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.

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.

Using TableQuery filters as parameter of findAll() doesn't work:

this.entityRepository
        .findAll(new TableQuery().where(filters));

It is because, even if it is not the case, the query is already specified within the findAll() on this line:

The query is already specified because the getter return the queryInstance by default:

Alternative solution: Specify the query directly into the repository:

this.entityRepository
        .where(filters)
        .findAll();

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

No batch operations

Expected behavior

Batch operations for update/delete.

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

Currently, I am searching for a way to use batch operations for updating and deleting. I have not found any option for this in the package. Is it planned to be implemented? Is there any workaround?

Cannot find module '@nestjs/azure-database' or its corresponding type declarations.

Installing version 2.0.0 from npm i --save @nestjs/azure-database

I'm submitting a security issue reported by Synk Scan
https://snyk.io/
It says Regular Expression Denial of Service (ReDoS)
introduced by @nestjs/[email protected] > [email protected] > [email protected]

Expected behavior

There should not be a vulnerability. Need to update the validator package

I am trying the azure database sample, and it was generated with default uuid string instead ContactName RowKey

[ ] 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

Expected behavior

Minimal reproduction of the problem with instructions

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

Environment

Nest version: 7.0.3

 
For Tooling issues:
- Node version:  10.14  
- Platform:  Windows 

Others:

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

using generateUuid from @azure/ms-rest-js. The package is no longer actively maintained. An alternative is to use the uuid npm package, or most recent NodeJS crypto.randomUUID (added in v14.17.0)

Expected behavior

An alternative is to use the uuid npm package, or most recent NodeJS crypto.randomUUID (added in v14.17.0)

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

I followed the Cosmos DB section of this guide. I am using
When running the app with nest start, I get the following compilation error:

node_modules/@nestjs/azure-database/dist/table-storage/azure-table.service.d.ts:2:22 - error TS2420: Class 'AzureTableStorageService' incorrectly implements interface 'TableService'.
  Property 'host' is missing in type 'AzureTableStorageService' but required in type 'TableService'.

2 export declare class AzureTableStorageService implements azure.TableService {
                       ~~~~~~~~~~~~~~~~~~~~~~~~

  node_modules/azure-storage/typings/azure-storage/azure-storage.d.ts:9330:11
    9330           host: StorageHost;
                   ~~~~
    'host' is declared here.

Found 1 error(s).

The error seems entirely contained inside of Azure's dependency, so I am guessing it is a versioning problem because I can't think of any code I wrote that would cause this.

Expected behavior

Normally with this kind of guide I would run in to some issue with Azure configuration or a problem with my code. Not a problem within @nestjs/azure-database

Minimal reproduction of the problem with instructions

Follow the guide as mentioned. Package json is below:
{ "name": "xxxxxxx", "version": "0.0.1", "description": "", "author": "", "private": true, "license": "UNLICENSED", "scripts": { "prebuild": "rimraf dist", "build": "nest build", "format": "prettier --write \"src/**/*.ts\" \"test/**/*.ts\"", "start": "nest start", "start:dev": "nest start --watch", "start:debug": "nest start --debug --watch", "start:prod": "node dist/main", "lint": "eslint \"{src,apps,libs,test}/**/*.ts\" --fix", "test": "jest", "test:watch": "jest --watch", "test:cov": "jest --coverage", "test:debug": "node --inspect-brk -r tsconfig-paths/register -r ts-node/register node_modules/.bin/jest --runInBand", "test:e2e": "jest --config ./test/jest-e2e.json" }, "dependencies": { "@nestjs/azure-database": "^2.0.1", "@nestjs/common": "^7.6.13", "@nestjs/config": "^0.6.3", "@nestjs/core": "^7.6.13", "@nestjs/passport": "^7.1.5", "@nestjs/platform-express": "^7.6.13", "@nestjs/swagger": "^4.7.15", "@types/passport-azure-ad": "^4.0.8", "class-transformer": "^0.4.0", "class-validator": "^0.13.1", "dotenv": "^8.2.0", "passport": "^0.4.1", "passport-azure-ad": "^4.3.0", "reflect-metadata": "^0.1.13", "rimraf": "^3.0.2", "rxjs": "^6.6.6" }, "devDependencies": { "@nestjs/cli": "^7.5.6", "@nestjs/schematics": "^7.2.7", "@nestjs/testing": "^7.6.13", "@types/express": "^4.17.11", "@types/jest": "^26.0.20", "@types/node": "^14.14.31", "@types/supertest": "^2.0.10", "@typescript-eslint/eslint-plugin": "^4.15.2", "@typescript-eslint/parser": "^4.15.2", "eslint": "^7.20.0", "eslint-config-prettier": "^8.1.0", "eslint-plugin-prettier": "^3.3.1", "jest": "^26.6.3", "prettier": "^2.2.1", "supertest": "^6.1.3", "ts-jest": "^26.5.2", "ts-loader": "^8.0.17", "ts-node": "^9.1.1", "tsconfig-paths": "^3.9.0", "typescript": "^4.1.5" }, "jest": { "moduleFileExtensions": [ "js", "json", "ts" ], "rootDir": "src", "testRegex": ".*\\.spec\\.ts$", "transform": { "^.+\\.(t|j)s$": "ts-jest" }, "collectCoverageFrom": [ "**/*.(t|j)s" ], "coverageDirectory": "../coverage", "testEnvironment": "node" } }

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

I need to get this app to compile so I can actually write code.

Environment

Nest version: 2.0.1

 
For Tooling issues:
- Node version: v14.15.5  
- Platform:  macOS Big Sur 11.1

Others:

Using intelliJ 2020.3.1 and nestJS version 7.5.6

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

We have one table with several entities
Some entities have the same partitionKey.
Each entities have a unique RowKey

When we process two updates at the same time with same PartitionKey but different RowKey we have a strange behavior => the two entities are mixed with same content

I noticed the lib use azure replaceEntity to do an update. When testing same case with Microsoft lib and mergeEntity function we don t have the issue, but I would prefer to use nest lib as it’s integration is more interesting with Nest

Expected behavior

Each updated entities are correctly and independently updated

Minimal reproduction of the problem with instructions

Create to update at the same time

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

Environment

Nest version: 6.9 to 7.0

 
For Tooling issues:
- Node version: 10.14 and + 
- Platform:  Mac. Linux and Windows

Others:
Package manager : npm

I'm submitting a...

[x] Feature request

Current behavior

this.catRepository.find(rowKey, new Cat());

Expected behavior

this.catRepository.find(new Cat({rowKey}));

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

Expected behavior

When running

npm i --save @nestjs/azure-database

i do not get the cosmos db part, could you please update the registry on npm?

Minimal reproduction of the problem with instructions

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

Environment

Nest version: X.Y.Z

 
For Tooling issues:
- Node version: 12.18    
- npm version: 6.14
- Platform: Mac 

Others:

This would be simple to add. Here are the steps:

1. Update https://github.com/nestjs/azure-database/blob/master/lib/table-storage/azure-table.repository.ts#L107 to:

async create(entity: T, rowKeyValue?: string): Promise<T> {

2. Update https://github.com/nestjs/azure-database/blob/master/lib/table-storage/azure-table.repository.ts#L110 to:

entity = AzureEntityMapper.createEntity<T>(entity, rowKeyValue );

3. update specs files.

I'm submitting an undocumented expectation for strictNullChecks to be false.

[ ] Regression 
[x] 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

After creating a new nest project and setting up azure-database with the default setup and following the azure-database documentation, we run into the following error:

src/contact/contact.service.ts:9:6 - error TS1239: Unable to resolve signature of parameter decorator when called as an expression.
  Argument of type 'undefined' is not assignable to parameter of type 'string | symbol'.

9     @InjectRepository(Contact)
       ~~~~~~~~~~~~~~~~~~~~~~~~~

This line seems to throw an error:

8   constructor(
9     @InjectRepository(Contact)
10    private readonly contactRepository: Repository<Contact>,
11  ) {}

When updating the tsconfig.json to strictNullChecks to false, the samples work now.

Expected behavior

Either the documentation should state that strictNullChecks must be set to false, or preferably the library should work with strictNullChecks set to true.

Minimal reproduction of the problem with instructions

Creating a new nest project and setting up azure-database with the default setup.

$ npm i -g @nestjs/cli
$ nest new project-name
$ cd project-name/
$ npm i --save @nestjs/azure-database

Then set up the sample following the documentation.

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

It took a while to figure out the null checks were the issue.

Environment

default nest tsconfig.json:

{
  "compilerOptions": {
    "module": "commonjs",
    "declaration": true,
    "removeComments": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "allowSyntheticDefaultImports": true,
    "target": "ES2021",
    "sourceMap": true,
    "outDir": "./dist",
    "baseUrl": "./",
    "incremental": true,
    "skipLibCheck": true,
    "strictNullChecks": true,
    "noImplicitAny": true,
    "strictBindCallApply": true,
    "forceConsistentCasingInFileNames": true,
    "noFallthroughCasesInSwitch": true
  }
}

Nest version: 10.0.0

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

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

FROM DOC:

You can optionally pass in the following arguments:

AzureTableStorageModule.forFeature(Contact, {
  table: 'AnotherTableName',
  createTableIfNotExists: true,
})

Expected behavior

Should be optional !

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

Expected behavior

Minimal reproduction of the problem with instructions

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

Environment

Nest version: X.Y.Z

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

Others:

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

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update dependency node to 20.12 (node, @types/node)
• chore(deps): update node.js to v21.7
• fix(deps): update dependency reflect-metadata to v0.2.2
• chore(deps): update dependency eslint to v9
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

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

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

The package currently only accepts a single partition key of type string for each entity/container and hard codes that as the first item of the partitionKey array.

However, CosmosDB supports up to 3 hierarchical partition keys.

Expected behavior

The preferred behavior would be to update the @CosmosPartitionKey() decorator to accept an array of up to 3 values or allow you to provide the entire containerOptions.partitionKey object yourself.

Minimal reproduction of the problem with instructions

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

I currently cannot implement a common data architecture due to the lack of support for a common feature.

Environment

Nest version: 10.3.0

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

Others:

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 Gitter badge in the README.md file is invalid.

Expected behavior

All other Repos in this Organisation have a working discord link. I am guessing this one must have a discord link.

I'm submitting a...

It is possible to pass the dynamic value to the decorator likeEntityPartitionKey | EntityRowKey?

[ ] 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

@EntityPartitionKey('CatID') is accepting the string but my paritionKey will be dynamic. It is based on the Entity value.

Expected behavior

Something i want is like
@EntityPartitionKey(data => data.Id + data.Name)

Minimal reproduction of the problem with instructions

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

Environment

Nest version: 6.9.0

 
For Tooling issues:
- Node version:   v10.17.0
- Platform:   Linux

Others:

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

I would like to query the Azure Table Storage Database using a Table Query. There isn't any documentation here on how that can be achieved. My approach (probably wrong) has been to do the following:

import { TableQuery } from 'azure-storage';
import { Repository } from '@nestjs/azure-database';

export class SomeService {
    constructor(
        @InjectRepository(EntitySchema)
        private readonly entityRepo: Repository
    ) {}
    
   async findSpecific(entityProperty: string): Promise {
       const query = new TableQuery();
       return await this.entityRepo.findAll(query.where(`property == ${entityPropery}`));
   }

The error I am getting from this is: The requested operation is not implemented on the specified resource.

Expected behavior

The query returns the defined results.

Environment

Nest version: 8.2.3

 
For Tooling issues:
- Node version: v17.2.0
- Platform:  MacOS

Others:

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

Hi there,

I am using "@nestjs/azure-database" v.2.3.0 in my NestJS API. Whenever an operation is executed with an Azure table concret Repository I get lots of console Debug logs like:

[Nest] 3334701  - 05/14/2023, 2:14:03 PM   DEBUG [AzureStorageRepository] Inserting Entity in {table_name}:
[Nest] 3334701  - 05/14/2023, 2:14:03 PM   DEBUG [AzureEntityMapper] Mapped Entity from DTO:
[Nest] 3334701  - 05/14/2023, 2:14:03 PM   DEBUG [AzureEntityMapper] - PartitionKey={partition_key}
[Nest] 3334701  - 05/14/2023, 2:14:03 PM   DEBUG [AzureEntityMapper] - RowKey=2de42a5d-6635-4ec1-aed9-e68d21b1900e

Did not found any reference on how to disable the DEBUG level logging from the package itself. I tried several solutions from either
disabling the console.debug callback (package continues to add DEBUG logs) to specifying the allowed log levels on NestJS app bootstrapping. None seems to disable the nestjs/azure-database package to add DEBUG logs.

Is there any specific way to achieve this?

Regards.

Expected behavior

No DEBUG log should be present in the console.

Minimal reproduction of the problem with instructions

Install nestjs/azure-database into a nestJS app.
Implement a concrete repository call to any CRUP op with a desired object structure.

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

Just using the library to store data in Azure Table Storage.

Environment

Nest version: X.Y.Z

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

Others:

pwd
.../azure-database/sample/cosmos-db

npm i
npm run build
npm run start

> [email protected] start /Volumes/data/workspace/draft/azure-db/azure-database/sample/cosmos-db
> nest start

[Nest] 72867   - 04/13/2020, 1:04:02 AM   [NestFactory] Starting Nest application...
[Nest] 72867   - 04/13/2020, 1:04:02 AM   [InstanceLoader] AppModule dependencies initialized +17ms
[Nest] 72867   - 04/13/2020, 1:04:02 AM   [InstanceLoader] AzureCosmosDbModule dependencies initialized +1ms
[Nest] 72867   - 04/13/2020, 1:04:02 AM   [ExceptionHandler] Nest can't resolve dependencies of the ContactService (?). Please make sure that the argument ContactRepository at index [0] is available in the ContactModule context.

Potential solutions:
- If ContactRepository is a provider, is it part of the current ContactModule?
- If ContactRepository is exported from a separate @Module, is that module imported within ContactModule?
  @Module({
    imports: [ /* the Module containing ContactRepository */ ]
  })
 +1ms
Error: Nest can't resolve dependencies of the ContactService (?). Please make sure that the argument ContactRepository at index [0] is available in the ContactModule context.

Potential solutions:
- If ContactRepository is a provider, is it part of the current ContactModule?
- If ContactRepository is exported from a separate @Module, is that module imported within ContactModule?
  @Module({
    imports: [ /* the Module containing ContactRepository */ ]
  })

    at Injector.lookupComponentInParentModules (/Volumes/data/workspace/draft/azure-db/azure-database/sample/cosmos-db/node_modules/@nestjs/core/injector/injector.js:191:19)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async Injector.resolveComponentInstance (/Volumes/data/workspace/draft/azure-db/azure-database/sample/cosmos-db/node_modules/@nestjs/core/injector/injector.js:147:33)
    at async resolveParam (/Volumes/data/workspace/draft/azure-db/azure-database/sample/cosmos-db/node_modules/@nestjs/core/injector/injector.js:101:38)
    at async Promise.all (index 0)
    at async Injector.resolveConstructorParams (/Volumes/data/workspace/draft/azure-db/azure-database/sample/cosmos-db/node_modules/@nestjs/core/injector/injector.js:116:27)
    at async Injector.loadInstance (/Volumes/data/workspace/draft/azure-db/azure-database/sample/cosmos-db/node_modules/@nestjs/core/injector/injector.js:80:9)
    at async Injector.loadProvider (/Volumes/data/workspace/draft/azure-db/azure-database/sample/cosmos-db/node_modules/@nestjs/core/injector/injector.js:37:9)
    at async Promise.all (index 3)
    at async InstanceLoader.createInstancesOfProviders (/Volumes/data/workspace/draft/azure-db/azure-database/sample/cosmos-db/node_modules/@nestjs/core/injector/instance-loader.js:42:9)

Current behavior

Expected behavior

Minimal reproduction of the problem with instructions

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

Environment

node -v
v12.16.2

 npm -v
6.14.4

macos 10.14.6

I'm submitting a bug/request for help

[ ] Regression 
[ x] 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

When nest starts up and the cosmos connection is created it hangs and times out. Tried same creds with c# and explicit gateway mode and its working.

Expected behavior

nest azure-database module can connect to cosmos hosted in azure.

Minimal reproduction of the problem with instructions

1. Create a cosmos db in azure.
2. Enter in the connection details in the AzureCosmosDbModule setup.
3. Start up the app.
4. Hit any path in nest where controller uses cosmos connection. App hangs and times out.

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

ReadMe

Environment

Nest version: 8.0.0

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

Others:

getModelToken should be exported so that it's possible to provide stable test doubles.

Given service like this:

export class SomeService {
  constructor(@InjectModel(SomeEntity) private readonly container: Container) {}
}

What we have to do now:

Test.createTestingModule({
  providers: [
    SomeService,
    { provide: `${SomeEntity}AzureCosmosDbModel`, useValue: jest.mocked({}) },
  ],
});

How it should be:

Test.createTestingModule({
  providers: [
    SomeService,
    { provide: getModelToken(SomeEntity), useValue: jest.mocked({}) },
  ],
});

Te package no contains Cosmos DB library only contents Table Storage 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

Based on your doc, it should be possible to use a forRoot on the main module to configure the connection but when I use it:

app.module.ts:

@Module({
  imports: [
    AzureTableStorageModule.forRoot({
      connectionString:
        'DefaultEndpointsProtocol=**********************************',
    }),
    CatModule,
  ],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}

cat.module.ts:

@Module({
  imports: [
    AzureTableStorageModule.forFeature(Cat, {
      table: 'Cat',
      createTableIfNotExists: true,
    }),
  ],
  providers: [CatService],
  controllers: [CatController],
})
export class CatModule {}

I got an error about a provider not available:

[Nest] 26448   - 12/18/2019, 8:41:44 AM   [AzureTableStorage] Create new TableService instance
[Nest] 26448   - 12/18/2019, 8:41:44 AM   [ExceptionHandler] Nest can't resolve dependencies of the AzureTableStorageRepository (AzureTableStorageService, ?). Please make sure that the argument AZURE_TABLE_STORAGE_NAME at index [1] is available in the AzureTableStorageModule context.

Potential solutions:
- If AZURE_TABLE_STORAGE_NAME is a provider, is it part of the current AzureTableStorageModule?
- If AZURE_TABLE_STORAGE_NAME is exported from a separate @Module, is that module imported within AzureTableStorageModule?
  @Module({
    imports: [ /* the Module containing AZURE_TABLE_STORAGE_NAME */ ]
  })
 +2ms
Error: Nest can't resolve dependencies of the AzureTableStorageRepository (AzureTableStorageService, ?). Please make sure that the argument AZURE_TABLE_STORAGE_NAME at index [1] is available in the AzureTableStorageModule context.

Potential solutions:
- If AZURE_TABLE_STORAGE_NAME is a provider, is it part of the current AzureTableStorageModule?
- If AZURE_TABLE_STORAGE_NAME is exported from a separate @Module, is that module imported within AzureTableStorageModule?
  @Module({
    imports: [ /* the Module containing AZURE_TABLE_STORAGE_NAME */ ]
  })

    at Injector.lookupComponentInParentModules (/home/kiwi/dev/azure-db/node_modules/@nestjs/core/injector/injector.js:190:19)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async Injector.resolveComponentInstance (/home/kiwi/dev/azure-db/node_modules/@nestjs/core/injector/injector.js:146:33)
    at async resolveParam (/home/kiwi/dev/azure-db/node_modules/@nestjs/core/injector/injector.js:100:38)
    at async Promise.all (index 1)
    at async Injector.resolveConstructorParams (/home/kiwi/dev/azure-db/node_modules/@nestjs/core/injector/injector.js:115:27)
    at async Injector.loadInstance (/home/kiwi/dev/azure-db/node_modules/@nestjs/core/injector/injector.js:79:9)
    at async Injector.loadProvider (/home/kiwi/dev/azure-db/node_modules/@nestjs/core/injector/injector.js:36:9)
    at async Promise.all (index 4)
    at async InstanceLoader.createInstancesOfProviders (/home/kiwi/dev/azure-db/node_modules/@nestjs/core/injector/instance-loader.js:41:9)

Expected behavior

I expect to not have any error when I am using forRoot instead of .env

Minimal reproduction of the problem with instructions

https://github.com/jogelin/nestjs-azure-database-sample/tree/issue-for-root

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

On npm run start:dev getting the following error -

ERROR [ExceptionHandler] Nest can't resolve dependencies of the AzureCosmosDbCoreModule (COSMOS_DB_CONNECTION_NAME, ?)

Others having the same issue - https://stackoverflow.com/questions/73731641/how-to-establish-cosmos-db-database-connection-with-nestjs-v9-0-0

Potential solutions:

• If ModuleRef is a provider, is it part of the current AzureCosmosDbCoreModule?
• If ModuleRef is exported from a separate @module, is that module imported within AzureCosmosDbCoreModule?
  @module({
  imports: [ /* the Module containing ModuleRef */ ]
  })

Error: Nest can't resolve dependencies of the AzureCosmosDbCoreModule (COSMOS_DB_CONNECTION_NAME, ?). Please make sure that the argument ModuleRef at index [1] is available in the AzureCosmosDbCoreModule context.

Minimum reproduction code

node 14 & 16, nestjs/common "^9.0.0"

Steps to reproduce

npm run start:dev

Using cosmos installation -

https://www.learmoreseekmore.com/2022/05/crud-operation-demo-on-nestjs-using-azure-cosmos-db.html

Expected behavior

Fetch data from cosmos db successfully.

Package

• I don't know. Or some 3rd-party package
• @nestjs/common
• @nestjs/core
• @nestjs/microservices
• @nestjs/platform-express
• @nestjs/platform-fastify
• @nestjs/platform-socket.io
• @nestjs/platform-ws
• @nestjs/testing
• @nestjs/websockets
• Other (see below)

Other package

No response

NestJS version

9.1.2

Packages versions

{
    "@azure/cosmos": "^3.17.1",
    "@azure/functions": "^1.0.3",
    "@nestjs/azure-database": "^2.3.0",
    "@nestjs/azure-func-http": "^0.8.0",
    "@nestjs/common": "^9.1.2",
    "@nestjs/config": "^2.2.0",
    "@nestjs/core": "^9.1.2",
    "@nestjs/mapped-types": "*",
    "@nestjs/platform-express": "^9.1.2",
    "@nestjs/sequelize": "^9.0.0",
    "@nestjs/swagger": "^6.1.2",
    "json2csv": "^5.0.7",
    "jspdf": "^2.5.1",
    "jspdf-autotable": "^3.5.25",
    "moment": "^2.29.4",
    "mysql2": "^2.3.3",
    "reflect-metadata": "^0.1.13",
    "rimraf": "^3.0.2",
    "rxjs": "^7.2.0",
    "sequelize": "^6.21.4",
    "sequelize-typescript": "^2.1.3",
    "tedious": "^15.0.1"
  }

Node.js version

16.16.0

In which operating systems have you tested?

• macOS
• Windows
• Linux

Other

No response

This package is also working with Cosmos DB mongodb API? Or it's preferable to use mongoose?

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

In the documentation it said to get key from keys section under settings, seems it doesn't exists anymore, there is a connection string section, not sure what should be put in the .env file

Expected behavior

Minimal reproduction of the problem with instructions

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

Environment

Nest version: 7

 
For Tooling issues:
- Node version: 12
- Platform:  Max

Others:

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

Connection string set to UseDevelopmentStorage=true results in error message Credentials must be provided when creating a service client.

Expected behaviour

Connection strings work as documented by Microsoft

Minimal reproduction of the problem with instructions

See current behaviour

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

For the particular example: Local development using azurite
In general: azure-storage module is officially deprecated. Microsoft doesn't recommend to use this module anymore

Environment

Nest version: X.Y.Z

 
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

This package only supports Table Storage.

Expected behavior

We need to support the Cosmos DB API.

Others:

Here are some resources links:

• Welcome to Azure Cosmos DB
• Quickstart: Build a Node.js app using Azure Cosmos DB SQL API account
• The @azure/cosmos JavaScript SDK

Notes:

Ideally, we would need to design a public API that is somehow similar to the current AzureTableStorageModule. We want the user to simply switch from AzureTableStorageModule to AzureCosmosDBModule without impacting their code.

To some extent, the user should be able to follow the Getting started and simply use the new AzureCosmosDBModule module.