@mastra/libsql 1.6.4 → 1.7.0

package/dist/docs/references/docs-rag-retrieval.md

@@ -1,10 +1,10 @@
-# Retrieval in RAG Systems
+# Retrieval in RAG systems
 
 After storing embeddings, you need to retrieve relevant chunks to answer user queries.
 
 Mastra provides flexible retrieval options with support for semantic search, filtering, and re-ranking.
 
-## How Retrieval Works
+## How retrieval works
 
 1. The user's query is converted to an embedding using the same model used for document embeddings
 2. This embedding is compared to stored embeddings using vector similarity
@@ -14,7 +14,7 @@ Mastra provides flexible retrieval options with support for semantic search, fil
 - Re-ranked for better relevance
 - Processed through a knowledge graph
 
-## Basic Retrieval
+## Basic retrieval
 
 The simplest approach is direct semantic search. This method uses vector similarity to find chunks that are semantically similar to the query:
 
@@ -63,7 +63,7 @@ Results include both the text content and a similarity score:
 ]
 ```
 
-## Advanced Retrieval options
+## Advanced retrieval options
 
 ### Metadata Filtering
 

package/dist/docs/references/docs-workflows-snapshots.md

@@ -150,7 +150,7 @@ export const mastra = new Mastra({
 1. **Ensure Serializability**: Any data that needs to be included in the snapshot must be serializable (convertible to JSON).
 2. **Minimize Snapshot Size**: Avoid storing large data objects directly in the workflow context. Instead, store references to them (like IDs) and retrieve the data when needed.
 3. **Handle Resume Context Carefully**: When resuming a workflow, carefully consider what context to provide. This will be merged with the existing snapshot data.
-4. **Set Up Proper Monitoring**: Implement monitoring for suspended workflows, especially long-running ones, to ensure they are properly resumed.
+4. **Set Up Proper Monitoring**: Implement monitoring for suspended workflows, especially long-running ones, to ensure they're properly resumed.
 5. **Consider Storage Scaling**: For applications with many suspended workflows, ensure your storage solution is appropriately scaled.
 
 ## Custom snapshot metadata

package/dist/docs/references/reference-core-getMemory.md

@@ -22,7 +22,7 @@ const thread = await memory.createThread({
 
 **memory** (`TMemory[TMemoryKey]`): The memory instance with the specified key. Throws an error if the memory is not found.
 
-## Example: Registering and Retrieving Memory
+## Example: Registering and retrieving memory
 
 ```typescript
 import { Mastra } from '@mastra/core'

package/dist/docs/references/reference-core-listMemory.md

@@ -20,7 +20,7 @@ This method takes no parameters.
 
 **memory** (`Record<string, MastraMemory>`): An object containing all registered memory instances, keyed by their registry keys.
 
-## Example: Checking Registered Memory
+## Example: Checking registered memory
 
 ```typescript
 import { Mastra } from '@mastra/core'

package/dist/docs/references/reference-core-mastra-class.md

@@ -1,4 +1,4 @@
-# Mastra Class
+# Mastra class
 
 The `Mastra` class is the central orchestrator in any Mastra application, managing agents, workflows, storage, logging, observability, and more. Typically, you create a single instance of `Mastra` to coordinate your application.
 
@@ -41,7 +41,7 @@ Visit the [Configuration reference](https://mastra.ai/reference/configuration) f
 
 **logger** (`Logger`): Logger instance created with new PinoLogger() (Default: `Console logger with INFO level`)
 
-**idGenerator** (`() => string`): Custom ID generator function. Used by agents, workflows, memory, and other components to generate unique identifiers.
+**idGenerator** (`(context?: IdGeneratorContext) => string`): Custom ID generator function. Used by agents, workflows, memory, and other components to generate unique identifiers. Receives optional context such as idType, source, entityId, and threadId to support context-aware ID formats.
 
 **workflows** (`Record<string, Workflow>`): Workflows to register. Structured as a key-value pair, with keys being the workflow name and values being the workflow instance. (Default: `{}`)
 

package/dist/docs/references/reference-memory-memory-class.md

@@ -1,4 +1,4 @@
-# Memory Class
+# Memory class
 
 The `Memory` class provides a robust system for managing conversation history and thread-based message storage in Mastra. It enables persistent storage of conversations, semantic search capabilities, and efficient message retrieval. You must configure a storage provider for conversation history, and if you enable semantic recall you will also need to provide a vector store and embedder.
 

package/dist/docs/references/reference-storage-composite.md

@@ -1,4 +1,4 @@
-# Composite Storage
+# Composite storage
 
 `MastraCompositeStore` can compose storage domains from different providers. Use it when you need different databases for different purposes. For example, use LibSQL for memory and PostgreSQL for workflows.
 

package/dist/docs/references/reference-storage-dynamodb.md

@@ -1,8 +1,8 @@
-# DynamoDB Storage
+# DynamoDB storage
 
 The DynamoDB storage implementation provides a scalable and performant NoSQL database solution for Mastra, leveraging a single-table design pattern with [ElectroDB](https://electrodb.dev/).
 
-> **Observability Not Supported:** DynamoDB storage **does not support the observability domain**. Traces from the `DefaultExporter` cannot be persisted to DynamoDB, and Mastra Studio's observability features won't work with DynamoDB as your only storage provider. To enable observability, use [composite storage](https://mastra.ai/reference/storage/composite) to route observability data to a supported provider like ClickHouse or PostgreSQL.
+> **Observability Not Supported:** DynamoDB storage **doesn't support the observability domain**. Traces from the `DefaultExporter` can't be persisted to DynamoDB, and Mastra Studio's observability features won't work with DynamoDB as your only storage provider. To enable observability, use [composite storage](https://mastra.ai/reference/storage/composite) to route observability data to a supported provider like ClickHouse or PostgreSQL.
 
 > **Item Size Limit:** DynamoDB enforces a **400 KB maximum item size**. This limit can be exceeded when storing messages with base64-encoded attachments such as images. See [Handling large attachments](https://mastra.ai/docs/memory/storage) for workarounds including uploading attachments to external storage.
 
@@ -120,7 +120,7 @@ For local development, you can use [DynamoDB Local](https://docs.aws.amazon.com/
 
 **config.ttl** (`object`): TTL (Time To Live) configuration for automatic data expiration. Configure per entity type: thread, message, trace, eval, workflow\_snapshot, resource, score. Each entity config includes: enabled (boolean), attributeName (string, default: 'ttl'), defaultTtlSeconds (number).
 
-## TTL (Time To Live) Configuration
+## TTL (time to live) configuration
 
 DynamoDB TTL allows you to automatically delete items after a specified time period. This is useful for:
 
@@ -211,12 +211,12 @@ aws dynamodb update-time-to-live \
 1. Go to the DynamoDB console
 2. Select your table
 3. Go to "Additional settings" tab
-4. Under "Time to Live (TTL)", click "Manage TTL"
+4. Under "Time to Live (TTL)", select "Manage TTL"
 5. Enable TTL and specify the attribute name (default: `ttl`)
 
 > **Note:** DynamoDB deletes expired items within 48 hours after expiration. Items remain queryable until actually deleted.
 
-## AWS IAM Permissions
+## AWS IAM permissions
 
 The IAM role or user executing the code needs appropriate permissions to interact with the specified DynamoDB table and its indexes. Below is a sample policy. Replace `${YOUR_TABLE_NAME}` with your actual table name and `${YOUR_AWS_REGION}` and `${YOUR_AWS_ACCOUNT_ID}` with appropriate values.
 
@@ -246,7 +246,7 @@ The IAM role or user executing the code needs appropriate permissions to interac
 }
 ```
 
-## Key Considerations
+## Key considerations
 
 Before diving into the architectural details, keep these key points in mind when working with the DynamoDB storage adapter:
 
@@ -255,7 +255,7 @@ Before diving into the architectural details, keep these key points in mind when
 - **Understanding GSIs:** Familiarity with how the GSIs are structured (as per `TABLE_SETUP.md`) is important for understanding data retrieval and potential query patterns.
 - **ElectroDB:** The adapter uses ElectroDB to manage interactions with DynamoDB, providing a layer of abstraction and type safety over raw DynamoDB operations.
 
-## Architectural Approach
+## Architectural approach
 
 This storage adapter utilizes a **single-table design pattern** leveraging [ElectroDB](https://electrodb.dev/), a common and recommended approach for DynamoDB. This differs architecturally from relational database adapters (like `@mastra/pg` or `@mastra/libsql`) that typically use multiple tables, each dedicated to a specific entity (threads, messages, etc.).
 

package/dist/docs/references/reference-storage-libsql.md

@@ -1,4 +1,4 @@
-# libSQL Storage
+# libSQL storage
 
 [libSQL](https://docs.turso.tech/libsql) is an open-source, SQLite-compatible database that supports both local and remote deployments. It can be used to store message history, workflow snapshots, traces, and eval scores.
 

package/dist/docs/references/reference-vectors-libsql.md

@@ -1,4 +1,4 @@
-# libSQL Vector Store
+# libSQL vector store
 
 The libSQL storage implementation provides a SQLite-compatible vector search [libSQL](https://github.com/tursodatabase/libsql), a fork of SQLite with vector extensions, and [Turso](https://turso.tech/) with vector extensions, offering a lightweight and efficient vector database solution. It's part of the `@mastra/libsql` package and offers efficient vector similarity search with metadata filtering.
 
@@ -69,7 +69,7 @@ const results = await store.query({
 });
 ```
 
-## Constructor Options
+## Constructor options
 
 **url** (`string`): libSQL database URL. Use ':memory:' for in-memory database, 'file:dbname.db' for local file, or a libSQL-compatible connection string like 'libsql://your-database.turso.io'.
 
@@ -81,7 +81,7 @@ const results = await store.query({
 
 ## Methods
 
-### createIndex()
+### `createIndex()`
 
 Creates a new vector collection. The index name must start with a letter or underscore and can only contain letters, numbers, and underscores. The dimension must be a positive integer.
 
@@ -91,7 +91,7 @@ Creates a new vector collection. The index name must start with a letter or unde
 
 **metric** (`'cosine' | 'euclidean' | 'dotproduct'`): Distance metric for similarity search. Note: Currently only cosine similarity is supported by libSQL. (Default: `cosine`)
 
-### upsert()
+### `upsert()`
 
 Adds or updates vectors and their metadata in the index. Uses a transaction to ensure all vectors are inserted atomically - if any insert fails, the entire operation is rolled back.
 
@@ -103,7 +103,7 @@ Adds or updates vectors and their metadata in the index. Uses a transaction to e
 
 **ids** (`string[]`): Optional vector IDs (auto-generated if not provided)
 
-### query()
+### `query()`
 
 Searches for similar vectors with optional metadata filtering.
 
@@ -119,7 +119,7 @@ Searches for similar vectors with optional metadata filtering.
 
 **minScore** (`number`): Minimum similarity score threshold (Default: `0`)
 
-### describeIndex()
+### `describeIndex()`
 
 Gets information about an index.
 
@@ -135,25 +135,25 @@ interface IndexStats {
 }
 ```
 
-### deleteIndex()
+### `deleteIndex()`
 
 Deletes an index and all its data.
 
 **indexName** (`string`): Name of the index to delete
 
-### listIndexes()
+### `listIndexes()`
 
 Lists all vector indexes in the database.
 
 Returns: `Promise<string[]>`
 
-### truncateIndex()
+### `truncateIndex()`
 
 Removes all vectors from an index while keeping the index structure.
 
 **indexName** (`string`): Name of the index to truncate
 
-### updateVector()
+### `updateVector()`
 
 Update a single vector by ID or by metadata filter. Either `id` or `filter` must be provided, but not both.
 
@@ -169,7 +169,7 @@ Update a single vector by ID or by metadata filter. Either `id` or `filter` must
 
 **update.metadata** (`Record<string, any>`): New metadata to update
 
-### deleteVector()
+### `deleteVector()`
 
 Deletes a specific vector entry from an index by its ID.
 
@@ -177,7 +177,7 @@ Deletes a specific vector entry from an index by its ID.
 
 **id** (`string`): ID of the vector entry to delete
 
-### deleteVectors()
+### `deleteVectors()`
 
 Delete multiple vectors by IDs or by metadata filter. Either `ids` or `filter` must be provided, but not both.
 
@@ -187,7 +187,7 @@ Delete multiple vectors by IDs or by metadata filter. Either `ids` or `filter` m
 
 **filter** (`Record<string, any>`): Metadata filter to identify vectors to delete (mutually exclusive with ids)
 
-## Response Types
+## Response types
 
 Query results are returned in this format:
 
@@ -200,7 +200,7 @@ interface QueryResult {
 }
 ```
 
-## Error Handling
+## Error handling
 
 The store throws specific errors for different failure cases:
 
@@ -232,7 +232,7 @@ Common error cases include:
 - Database connection issues
 - Transaction failures during upsert
 
-## Usage Example
+## Usage example
 
 ### Local embeddings with fastembed