Releases · datastax/astra-db-ts

Collection methods on the Db class (such as db.collection(), db.createCollection(), db.listCollections(), etc.) now have sister methods for tables:

db.table(),
db.createTable(),
db.listTables(),
etc.

Indexes

Furthermore, tables necessitate indexes, which may be created through table.createIndex() (and its sister methods), and dropped through db.dropTableIndex().

Utility types

New utility types to infer the table's TS-type from its schema has been added as well:

InferTableSchema
InferTablePrimaryKey

Datatypes

Lastly, of the major additions, new datatypes have been added as well to support the new tables:

DataAPIBlob
DataAPIDate
DataAPITime
DataAPIDuration
DataAPIInet
DataAPIVector
BigNumber (re-exported from bignumber.js)

See DATATYPES.md for more information on the new datatypes.

`findAndRerank` support

Note

This is tied to the Overhaul of cursors section; please read that section as well for more information.

Preview hybrid search support has dropped via the collection.findAndRerank() method, which uses a new FindAndRerankCursor to iterate over its results.

New LexicalDoc type added as well as a sister type to VectorDoc and VectorizeDoc.

Overhaul of the logging system*

The logging system has evolved beyond a simple, immutable monitorCommands flag which would emit events only on the DataAPIClient class.

Now, logging is configured through the logging option anywhere along the options hierarchy, and adds a variety of new features:

Events may log to the console as well now, as opposed to just being emitted as an event
All classes in the client hierarchy are now event listeners
- These all extend the HierarchicalLogger class, which implements a minimal event emitter
- Events are bubbled up from the class they were emitted from, all the way up to the root DataAPIClient
- Event bubbling may be cancelled through event.stop[Immediate]Propagation() like the DOM

Logging may also be enabled/disabled/reconfigured on the fly, via the .updateLoggingConfig(<config>) method on any HierarchicalLogger instance (e.g. DataAPIClient, Db, Collection, etc.).

See the logging examples for more information.

Overhaul of the timeout system*

The timeout system has been overhauled to be more flexible and descriptive than the current singular maxTimeMS.

Timeouts are now configured through the timeoutDefaults parameter on class options interfaces, and the timeout parameter on method calls.

They are represented by the TimeoutDescriptor class, which contains the six following keys:

Timeout Option	Description	Default
`requestTimeoutMs`	Maximum time the client waits for a response from the server	15 seconds
`generalMethodTimeoutMs`	Timeout for general methods without a specific override (mostly doc/row-level ops)	30 seconds
`collectionAdminTimeoutMs`	Timeout for collection admin operations (create, drop, list, etc.)	1 minute
`tableAdminTimeoutMs`	Timeout for table admin operations (create, drop, list, alter, create/dropIndex, etc.)	30 seconds
`databaseAdminTimeoutMs`	Timeout for database admin operations (create, drop, list, info, findEmbeddingProviders, etc.)	10 minutes
`keyspaceAdminTimeoutMs`	Timeout for keyspace admin operations (create, drop, list)	30 seconds

In general, the requestTimeoutMs always corresponds to a single request from the server, but the rest of the timeouts account for the entire duration of the method, which is relevant in the case of multi-call methods.

A few important notes:

requestTimeoutMs applies per individual HTTP request.
The other timeouts account for the entire duration of the method, which is relevant in the case of multi-call methods.
Passing a timeout value as a plain number will use the most appropriate category for the method being called.
Setting a timeout to 0 disables it completely.
The legacy maxTimeMS option has been removed—simply replace it with timeout for a quick migration path.