jcormont / documentdb-typescript Goto Github PK

Hi,

Getting this error when trying to use the Collection object:

babel-node app.js --presets es2015 /Users/shai/Development/***/src/node_modules/documentdb-typescript/dist/DocumentStream.js :13 Symbol.asyncIterator = Symbol.asyncIterator || Symbol("Symbol.asyncIterator"); TypeError: Cannot assign to read only property 'asyncIterator' of function 'function Symbol() { [native code] }' at Object.<anonymous> (/Users/shai/Development/***/src/node_modules/documentdb-typesc ript/dist/DocumentStream.js:13:22) at Module._compile (module.js:571:32) at Module._extensions..js (module.js:580:10) at Object.require.extensions.(anonymous function) [as .js] (/Users/shai/Development/***/src/node_modules/babel-register/lib/node.js:152:7) at Module.load (module.js:488:32) at tryModuleLoad (module.js:447:12) at Function.Module._load (module.js:439:3) at Module.require (module.js:498:17) at require (internal/module.js:20:19) at Object.<anonymous> (/Users/shai/Development/***/src/node_modules/documentdb-typesc ript/dist/Collection.js:12:26)

Putting the following line guarded by if (!Symbol.asyncIterator) fixed the issue for me.
Symbol.asyncIterator = Symbol.asyncIterator || Symbol("Symbol.asyncIterator");

The queryDocuments implementation in Collection only supports batchSize. There should be a way to pass other options, or at least enableCrossPartitionQuery.

For e.g. deleting a document, currently the API uses the _self property to get a unique document URL. This is not strictly required, since the id property can be used to construct an alternative URL as well.

See https://azure.microsoft.com/en-us/blog/azure-documentdb-bids-fond-farewell-to-self-links/

This opens up possibilities to overload or write alternative delete/update methods that use the id only, which makes things much simpler in some cases.

should be:

export interface ConnectionPolicy {
    DisableSSLVerification : boolean, // +++
    MediaReadMode?: "Buffered" | "Streamed";
    MediaRequestTimeout?: number;
    RequestTimeout?: number;
    EnableEndpointDiscovery?: boolean;
    PreferredLocations?: string[];
    RetryOptions: {
        MaxRetryAttemptCount?: number;
        FixedRetryIntervalInMilliseconds?: number;
        MaxWaitTimeInSeconds?: number;
    };
}

I'm not familiar with typescripts but we have a customer who wants to have the authoritative source for DocumentDB. Can he just install your package and have it working?

Does that includes all APIs as in Node.js SDK Release 1.11.0?

Do you know who maintains https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/documentdb/index.d.ts and if your version is more up-to-date, we should update the above?

Is there a tool to generate the .d.ts file from the nodejs source files of Node.js SDK or is this more of a manual work that you have done?

Hi! Great library.

Just a fyi for others that might be getting a socket disconnected error.
Check out the overview page for CosmoDB in the Azure portal for the URI.
It looks like: https://.documents.azure.com:443/

I struggled a bit in the beginning trying to get that right. Didn't have the :443 part.

When i call

    let doc: any = await getJsonFromWebRequest(REST_ENDPOINT_URL);
    await coll.storeDocumentAsync(doc, StoreMode.Upsert);

this gets executed:

tryStore = (callback) => this.database.client.log(data.id ? "Upserting document: " + data.id : "Upserting document.")

(Context here)

and because my JSON object has no id property, that ends up printing:
Upserting document: undefined

Should we probably change that to somethig like

tryStore = (callback) => this.database.client.log(data.id ? "Upserting document: " + data.id : "Upserting document.")

or am i missing something obvious and i'm doing it wrong?

When using the noImplicitAny compiler flag, the following compiler error occurs:

node_modules/documentdb-typescript/typings/_DocumentDB.d.ts(26,36): error TS7006: Parameter 'string' implicitly has an 'any' type.
node_modules/documentdb-typescript/typings/_DocumentDB.d.ts(27,37): error TS7006: Parameter 'string' implicitly has an 'any' type.

I've got the error, when I use getAccountInfoAsync. Other method works.

To reproduce, I just install this npm

$ npm install documentdb-typescript --save
[email protected] /Users/ushio/Codes/musclehack/spike/HttpTriggerJS
└─┬ [email protected] 
  └─┬ [email protected] 
    ├── [email protected] 
    ├── [email protected] 
    ├── [email protected] 
    └── [email protected] 

then create this ts file.

import * as DB from "documentdb-typescript";

async function main() {
    const client = new DB.Client("MY_COSMOS_HOST","MY_KEY");
    // enable logging of all operations to the console
    client.enableConsoleLog = true;
    
       // dump the account information
       console.log(await client.getAccountInfoAsync());
    
       // open the connection and print a list of IDs
       await client.openAsync();
       var dbs = await client.listDatabasesAsync();
       console.log(dbs.map(db => db.id));
    
       // unnecessary unless you expect new clients
       // to reopen the connection:
       client.close();
}

main();

Once, I comment out console.log(await client.getAccountInfoAsync()); It works well.

Any Ideas?

The variable concurrencyLimit is not exported from the main module properly and therefore cannot be set by the user.

Possible fix: move this variable to the main module itself and import it in Util (where it is enforced).

Idea

The best idea for supporting sprocs in a strongly typed way so far, is to maintain sprocs in application code as functions that return anonymous classes. Like so:

let mySproc = () => class extends Collection.Sproc {
    public getBar() { return "bar" }
    public run() {
        this.getResponse().setBody({ foo: this.getBar() });
    }
}

This can then be wrapped into a function (the actual sproc) that instantiates the class and calls run.

This means that we don't need an additional .d.ts file for the server side code, since everything is wrapped in the Sproc class, which just throws an error if it is constructed outside of the docdb server environment.

Function wrappers

It turns out that the server side environment supports Promise just fine! Even generators are supported. This opens up possibilities to use async/await in sprocs as well, if e.g. queryDocuments can be wrapped in a function that returns a query iterator just like on the client side, which then supports .forEach and handles continuations if needed.

Unanswered questions

• The sproc code needs to include some methods like __extend. How? Maybe it's better to keep every sproc in its own module, and send the entire module's code over.
• Would this allow sprocs to extend from each other? Can the wrapper be smart enough to also include the base class in the actual code sent to the server?

This can be used for:

• Partial<T> when searching by (partial) record, exact match on properties
• Result of finding a record: should be T & { _self: string, ... }
• other places...? (to investigate)

Right now the build scripts use the system version of tsc, which might not be what you want. For example, I don't have tsc installed globally at all.

If you add typescript to devDependencies then npm will automatically use the corresponding tsc binary in node_modules/.bin, so you can control the exact version of the TypeScript compiler.