{"schemaVersion":"1.0.0","docId":"adapters","source":"adapters","slug":"adapters","path":"/docs/adapters","raw_path":"/raw/adapters.md","title":"Adapters","headings":[],"documentType":"unknown","contentOrigin":"static-doc","canonicalUrl":"/docs/adapters/","buildId":"local-1782300258906","generatedAt":"2026-06-24T11:24:18.906Z","content":"---\ntitle: Adapters\nnavTitle: Adapters\ndescription: Storage adapters for the LakeQL write pipeline — Parquet generation, S3/MinIO uploads, and Hive table management.\nentrypoint: /docs/adapters/overview/introduction\n---\n","description":"Storage adapters for the LakeQL write pipeline — Parquet generation, S3/MinIO uploads, and Hive table management.","navTitle":"Adapters","keywords":["adapters","storage","lakeql","write","pipeline"]}
{"schemaVersion":"1.0.0","docId":"adapters/overview/hive-table-manager","source":"adapters","slug":"overview/hive-table-manager","path":"/docs/adapters/overview/hive-table-manager","raw_path":"/raw/adapters/overview/hive-table-manager.md","title":"Hive Table Manager","headings":[{"level":2,"text":"How it works","id":"how-it-works"},{"level":2,"text":"External table locations","id":"external-table-locations"},{"level":2,"text":"Table strategies","id":"table-strategies"},{"level":2,"text":"Usage","id":"usage"},{"level":2,"text":"Generated DDL","id":"generated-ddl"},{"level":2,"text":"Configuration","id":"configuration"},{"level":2,"text":"Table definition","id":"table-definition"}],"documentType":"unknown","contentOrigin":"static-doc","canonicalUrl":"/docs/adapters/overview/hive-table-manager/","buildId":"local-1782300258906","generatedAt":"2026-06-24T11:24:18.906Z","content":"---\ntitle: Hive Table Manager\nnavTitle: Hive Table Manager\ndescription: How the write pipeline manages Hive external tables in Trino.\n---\n\nThe Hive Table Manager is responsible for creating and maintaining external tables in Trino's Hive catalog. After the write pipeline uploads Parquet files to object storage, the table manager ensures a corresponding Hive table exists that points to that data — making it immediately queryable.\n\n## How it works\n\nEvery mutation write goes through this flow:\n\n1. Data is written as Parquet to S3/MinIO\n2. The existing Hive table is dropped (if present)\n3. A new external table is created pointing to the uploaded data\n\nThis \"drop + create\" approach ensures the table schema always matches the current data, even if fields were added or removed.\n\n## External table locations\n\nHive external tables point to a **directory** in object storage, not a single file. The table manager uses the `s3a://` URI scheme, which is required by Hive's underlying Hadoop FileSystem.\n\n```\ns3a://<bucket>/<basePath>/latest.parquet/\n         │         │              │\n         │         │              └─ Directory containing Parquet file(s)\n         │         └─ Configured basePath for the endpoint\n         └─ Configured bucket name\n```\n\n<Note>\n  The `s3a://` scheme is always used — regardless of whether the storage is AWS\n  S3 or MinIO. The standard `s3://` scheme is not recognized by Hadoop's\n  FileSystem.\n</Note>\n\n## Table strategies\n\nDepending on the [load strategy](/docs/adapters/write-pipeline/load-strategies), different tables are managed:\n\n| Strategy           | Tables created                                                               |\n| ------------------ | ---------------------------------------------------------------------------- |\n| `full_load`        | `<tableName>` → `latest.parquet/`                                            |\n| `full_load_append` | `<tableName>_latest` → `latest.parquet/`, `<tableName>_all` → `all.parquet/` |\n| `append`           | `<tableName>` → `all.parquet/`                                               |\n\nFor `full_load_append`, both tables are managed atomically — if creating one fails, the manager attempts a best-effort rollback by dropping both.\n\n## Usage\n\nThe table manager is typically used internally by `executeWritePipeline`. For direct usage:\n\n```ts\nimport { createHiveTableManager } from \"@lakeql/adapters\"\nimport { TrinoClient } from \"@lakeql/trino-client\"\n\nconst trinoClient = new TrinoClient({\n  host: \"https://trino.example.com\",\n  port: 8443,\n  auth: { type: \"basic\", username: \"admin\", password: \"secret\" },\n  catalog: \"hive\",\n})\n\nconst hiveManager = createHiveTableManager({\n  client: trinoClient,\n  bucket: \"my-datalake\",\n})\n\n// Build a properly formatted location URI\nconst location = hiveManager.buildExternalLocation(\n  \"analytics/events/latest.parquet/\"\n)\n// => \"s3a://my-datalake/analytics/events/latest.parquet/\"\n\n// Create a table pointing to that location\nawait hiveManager.recreateTable({\n  catalog: \"hive\",\n  schema: \"analytics\",\n  tableName: \"events\",\n  externalLocation: location,\n  columns: [\n    { name: \"event_id\", type: \"VARCHAR\" },\n    { name: \"message\", type: \"VARCHAR\" },\n    { name: \"created_at\", type: \"TIMESTAMP(3)\" },\n  ],\n})\n```\n\n## Generated DDL\n\nThe above produces:\n\n```sql\nDROP TABLE IF EXISTS hive.analytics.events;\n\nCREATE TABLE hive.analytics.events (\n  event_id VARCHAR,\n  message VARCHAR,\n  created_at TIMESTAMP(3)\n)\nWITH (\n  external_location = 's3a://my-datalake/analytics/events/latest.parquet/',\n  format = 'PARQUET'\n);\n```\n\n## Configuration\n\n<InterfaceReference\n  file=\"adapters/src/hive-table-manager\"\n  name=\"HiveTableManagerConfig\"\n  mode=\"declaration\"\n/>\n\n## Table definition\n\n<InterfaceReference\n  file=\"adapters/src/hive-table-manager\"\n  name=\"HiveTableDefinition\"\n  mode=\"declaration\"\n/>\n","description":"How the write pipeline manages Hive external tables in Trino.","navTitle":"Hive Table Manager","keywords":["table","external","manager","write","pipeline"]}
{"schemaVersion":"1.0.0","docId":"adapters/overview/introduction","source":"adapters","slug":"overview/introduction","path":"/docs/adapters/overview/introduction","raw_path":"/raw/adapters/overview/introduction.md","title":"Introduction","headings":[{"level":2,"text":"What it does","id":"what-it-does"},{"level":2,"text":"Package exports","id":"package-exports"},{"level":2,"text":"Architecture","id":"architecture"},{"level":2,"text":"Storage types","id":"storage-types"},{"level":2,"text":"Installation","id":"installation"}],"documentType":"unknown","contentOrigin":"static-doc","canonicalUrl":"/docs/adapters/overview/introduction/","buildId":"local-1782300258906","generatedAt":"2026-06-24T11:24:18.906Z","content":"---\ntitle: Introduction\nnavTitle: Introduction\ndescription: Overview of the @lakeql/adapters package and how it powers the mutation write pipeline.\n---\n\nThe `@lakeql/adapters` package provides the storage layer for LakeQL mutations. When a GraphQL mutation is executed, the adapters package handles everything from converting records to Parquet, uploading to object storage, and managing Hive external table DDL in Trino.\n\n## What it does\n\nThe package is responsible for three core tasks:\n\n1. **Parquet generation** — Converts input records to columnar Parquet format using `@lakeql/parquet`\n2. **Object storage** — Uploads Parquet files to S3 or S3-compatible storage (MinIO, etc.)\n3. **Hive DDL management** — Creates and manages external tables in Trino's Hive catalog so the data is immediately queryable\n\n## Package exports\n\nThe main entry point (`@lakeql/adapters`) exports storage operations, the write pipeline, and the Hive table manager. See the [API Reference](/docs/adapters/api-reference) for the full list of exports.\n\n## Architecture\n\n```mermaid\ngraph TD\n    A[GraphQL Mutation] --> B[executeWritePipeline]\n    B --> C[writeParquet]\n    B --> D[Storage Operations]\n    B --> E[Hive Table Manager]\n    C --> D\n    D --> F[S3 / MinIO]\n    E --> G[Trino DDL]\n```\n\nThe `executeWritePipeline` function orchestrates the full flow. It accepts records, a JSON Schema describing their shape, and a pipeline configuration that determines the load strategy, storage target, and table definition.\n\n## Storage types\n\nThe adapters support two storage backends:\n\n| Type    | Description                 | Credentials                                      |\n| ------- | --------------------------- | ------------------------------------------------ |\n| `s3`    | AWS S3                      | `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`     |\n| `minio` | S3-compatible (MinIO, etc.) | `MINIO_ACCESS_KEY_ID`, `MINIO_SECRET_ACCESS_KEY` |\n\nBoth use the same S3 protocol under the hood. The `minio` type requires an explicit `endpoint` configuration.\n\n## Installation\n\n<Command variant=\"install\">@lakeql/adapters</Command>\n\nPeer dependencies for S3/MinIO storage:\n\n<Command variant=\"install\">\n  @aws-sdk/client-s3 @aws-sdk/s3-presigned-post @aws-sdk/s3-request-presigner\n</Command>\n","description":"Overview of the @lakeql/adapters package and how it powers the mutation write pipeline.","navTitle":"Introduction","keywords":["package","introduction","overview","lakeqladapters","powers"]}
{"schemaVersion":"1.0.0","docId":"adapters/storage/storage-operations","source":"adapters","slug":"storage/storage-operations","path":"/docs/adapters/storage/storage-operations","raw_path":"/raw/adapters/storage/storage-operations.md","title":"Storage Operations","headings":[{"level":2,"text":"createStorageOperations","id":"create-storage-operations"},{"level":2,"text":"Configuration","id":"configuration"},{"level":2,"text":"Operations","id":"operations"},{"level":2,"text":"Environment variables","id":"environment-variables"},{"level":2,"text":"Error handling","id":"error-handling"}],"documentType":"unknown","contentOrigin":"static-doc","canonicalUrl":"/docs/adapters/storage/storage-operations/","buildId":"local-1782300258906","generatedAt":"2026-06-24T11:24:18.906Z","content":"---\ntitle: Storage Operations\nnavTitle: Storage Operations\ndescription: Low-level S3/MinIO storage operations for uploading and managing Parquet files.\n---\n\nStorage operations provide the low-level interface for interacting with S3 or S3-compatible object storage. The write pipeline uses these internally, but they are exported for advanced use cases.\n\n## createStorageOperations\n\nCreates a storage operations instance backed by `files-sdk`. The adapter selection is based on `config.type`:\n\n- `\"s3\"` — reads credentials from `AWS_*` environment variables\n- `\"minio\"` — reads credentials from `MINIO_*` environment variables\n\n```ts\nimport { createStorageOperations } from \"@lakeql/adapters\"\n\nconst storage = createStorageOperations({\n  type: \"minio\",\n  bucket: \"my-datalake\",\n  endpoint: \"http://localhost:9000\",\n})\n```\n\n## Configuration\n\n<InterfaceReference\n  file=\"adapters/src/storage-operations\"\n  name=\"StorageConfig\"\n  mode=\"declaration\"\n/>\n\n## Operations\n\nThe returned object provides these methods:\n\n| Method                 | Description                                           |\n| ---------------------- | ----------------------------------------------------- |\n| `upload(buffer, path)` | Upload a `Uint8Array` to the given path in the bucket |\n| `deletePrefix(prefix)` | Delete all objects under the given prefix             |\n\n## Environment variables\n\n### S3\n\n| Variable                | Description              |\n| ----------------------- | ------------------------ |\n| `AWS_ACCESS_KEY_ID`     | AWS access key           |\n| `AWS_SECRET_ACCESS_KEY` | AWS secret key           |\n| `AWS_DEFAULT_REGION`    | Default region           |\n| `AWS_ENDPOINT_URL`      | Optional custom endpoint |\n\n### MinIO\n\n| Variable                  | Description      |\n| ------------------------- | ---------------- |\n| `MINIO_ACCESS_KEY_ID`     | MinIO access key |\n| `MINIO_SECRET_ACCESS_KEY` | MinIO secret key |\n\n<Note>\n  The `endpoint` field in the config is required for MinIO. For S3, it's\n  optional and defaults to the standard AWS endpoint for the region.\n</Note>\n\n## Error handling\n\nStorage errors are wrapped in a `StorageError` with a descriptive message including the operation and path:\n\n```ts\nimport { StorageError } from \"@lakeql/adapters\"\n\ntry {\n  await storage.upload(buffer, \"path/to/file.parquet\")\n} catch (error) {\n  if (error instanceof StorageError) {\n    console.error(error.message)\n    // \"Storage upload failed for \"path/to/file.parquet\": The specified bucket does not exist\"\n  }\n}\n```\n\n<InlineReference\n  file=\"adapters/src/storage-operations\"\n  include={[\"StorageError\"]}\n/>\n","description":"Low-level S3/MinIO storage operations for uploading and managing Parquet files.","navTitle":"Storage Operations","keywords":["operations","storage","low-level","s3minio","uploading"]}
{"schemaVersion":"1.0.0","docId":"adapters/write-pipeline/execute-write-pipeline","source":"adapters","slug":"write-pipeline/execute-write-pipeline","path":"/docs/adapters/write-pipeline/execute-write-pipeline","raw_path":"/raw/adapters/write-pipeline/execute-write-pipeline.md","title":"executeWritePipeline","headings":[{"level":2,"text":"Signature","id":"signature"},{"level":2,"text":"Input","id":"input"},{"level":2,"text":"Configuration","id":"configuration"},{"level":2,"text":"Usage","id":"usage"},{"level":2,"text":"Pipeline steps","id":"pipeline-steps"}],"documentType":"unknown","contentOrigin":"static-doc","canonicalUrl":"/docs/adapters/write-pipeline/execute-write-pipeline/","buildId":"local-1782300258906","generatedAt":"2026-06-24T11:24:18.906Z","content":"---\ntitle: executeWritePipeline\nnavTitle: executeWritePipeline\ndescription: The main entry point for persisting mutation data through the write pipeline.\n---\n\n`executeWritePipeline` is the primary function for persisting GraphQL mutation input. It converts records to Parquet, uploads them to object storage, and manages the corresponding Hive external table in Trino.\n\n## Signature\n\n```ts\nfunction executeWritePipeline(input: WritePipelineInput): Promise<void>\n```\n\n## Input\n\n<InterfaceReference\n  file=\"adapters/src/write-pipeline\"\n  name=\"WritePipelineInput\"\n  mode=\"declaration\"\n/>\n\n## Configuration\n\n<InterfaceReference\n  file=\"adapters/src/write-pipeline\"\n  name=\"WritePipelineConfig\"\n  mode=\"declaration\"\n/>\n\n## Usage\n\n```ts\nimport { executeWritePipeline } from \"@lakeql/adapters\"\nimport { TrinoClient } from \"@lakeql/trino-client\"\n\nconst trinoClient = new TrinoClient({\n  host: \"https://trino.example.com\",\n  port: 8443,\n  auth: { type: \"basic\", username: \"admin\", password: \"secret\" },\n  catalog: \"hive\",\n})\n\nawait executeWritePipeline({\n  records: [\n    {\n      event_id: \"abc-123\",\n      message: \"Hello\",\n      timestamp: \"2025-01-15T10:30:00Z\",\n    },\n  ],\n  jsonSchema: {\n    type: \"object\",\n    properties: {\n      event_id: { type: \"string\" },\n      message: { type: \"string\" },\n      timestamp: { type: \"string\", format: \"date-time\" },\n    },\n  },\n  config: {\n    loadStrategy: \"full_load\",\n    type: \"minio\",\n    bucket: \"my-datalake\",\n    basePath: \"analytics/events\",\n    endpoint: \"http://localhost:9000\",\n    table: {\n      catalog: \"hive\",\n      schema: \"analytics\",\n      tableName: \"events\",\n    },\n    trinoClient,\n  },\n})\n```\n\n## Pipeline steps\n\nThe pipeline executes these steps in order:\n\n1. **Convert to Parquet** — Records are serialized to a Parquet buffer using the provided JSON Schema\n2. **Upload to storage** — The Parquet file is uploaded to the configured bucket/path\n3. **Manage Hive DDL** — The external table is dropped and recreated pointing to the new data location\n\nIf any step fails, the pipeline stops immediately and throws the error. There is no automatic rollback of earlier steps.\n\n<Note>\n  The `jsonSchema` property is typically generated by the CLI as\n  `json-schema.json` in each endpoint directory. You don't need to write it by\n  hand.\n</Note>\n","description":"The main entry point for persisting mutation data through the write pipeline.","navTitle":"executeWritePipeline","keywords":["pipeline","executewritepipeline","entry","point","persisting"]}
{"schemaVersion":"1.0.0","docId":"adapters/write-pipeline/load-strategies","source":"adapters","slug":"write-pipeline/load-strategies","path":"/docs/adapters/write-pipeline/load-strategies","raw_path":"/raw/adapters/write-pipeline/load-strategies.md","title":"Load Strategies","headings":[{"level":2,"text":"Available strategies","id":"available-strategies"},{"level":2,"text":"Partitioning interaction","id":"partitioning-interaction"}],"documentType":"unknown","contentOrigin":"static-doc","canonicalUrl":"/docs/adapters/write-pipeline/load-strategies/","buildId":"local-1782300258906","generatedAt":"2026-06-24T11:24:18.906Z","content":"---\ntitle: Load Strategies\nnavTitle: Load Strategies\ndescription: How full_load, full_load_append, and append strategies control data storage and table management.\n---\n\nThe `loadStrategy` configuration determines how new data is stored and how Hive tables are managed. Each strategy provides a different tradeoff between data freshness, history retention, and storage costs.\n\n## Available strategies\n\n### full_load\n\nThe default strategy. Replaces all existing data with the new records on every write.\n\n**Steps:**\n\n1. Delete all existing files at the base path\n2. Upload new Parquet file to `<basePath>/latest.parquet/<uuid>.parquet`\n3. Drop and recreate the Hive table pointing to the `latest.parquet/` directory\n\n**Use when:** You always want the table to reflect the most recent payload. No history is kept.\n\n**Table structure:**\n| Table | Location |\n|-------|----------|\n| `<tableName>` | `s3a://<bucket>/<basePath>/latest.parquet/` |\n\n### full_load_append\n\nCombines `full_load` with historical archiving. The latest data is always queryable, and all historical writes are preserved in an append-only directory.\n\n**Steps:**\n\n1. Upload Parquet file to `<basePath>/latest.parquet/<uuid>.parquet` (replaces previous)\n2. Upload the same Parquet file to `<basePath>/all.parquet/<partition_path>`\n3. Drop and recreate both `_latest` and `_all` Hive tables\n\n**Use when:** You need both a \"current state\" view and a historical log of all writes.\n\n**Table structure:**\n| Table | Location |\n|-------|----------|\n| `<tableName>_latest` | `s3a://<bucket>/<basePath>/latest.parquet/` |\n| `<tableName>_all` | `s3a://<bucket>/<basePath>/all.parquet/` |\n\n### append\n\nOnly appends data. No \"latest\" snapshot is maintained.\n\n**Steps:**\n\n1. Upload Parquet file to `<basePath>/all.parquet/<partition_path>`\n2. Drop and recreate the Hive table pointing to the `all.parquet/` directory\n\n**Use when:** You're building a log or event stream where every write adds to the history.\n\n**Table structure:**\n| Table | Location |\n|-------|----------|\n| `<tableName>` | `s3a://<bucket>/<basePath>/all.parquet/` |\n\n## Partitioning interaction\n\nFor `full_load`, partitioning configuration is ignored — data is always written as a single file in `latest.parquet/`.\n\nFor `full_load_append` and `append`, the partition path within `all.parquet/` is determined by the [partitioning configuration](/docs/adapters/write-pipeline/partitioning).\n\n<Note>\n  The `full_load` strategy deletes the entire base path before uploading. Make\n  sure you don't share the `basePath` between multiple endpoints.\n</Note>\n","description":"How full_load, full_load_append, and append strategies control data storage and table management.","navTitle":"Load Strategies","keywords":["strategies","fullload","fullloadappend","append","control"]}
{"schemaVersion":"1.0.0","docId":"adapters/write-pipeline/partitioning","source":"adapters","slug":"write-pipeline/partitioning","path":"/docs/adapters/write-pipeline/partitioning","raw_path":"/raw/adapters/write-pipeline/partitioning.md","title":"Partitioning","headings":[{"level":2,"text":"Partitioning modes","id":"partitioning-modes"},{"level":2,"text":"Timestamp mode","id":"timestamp-mode"},{"level":2,"text":"Disabled mode","id":"disabled-mode"},{"level":2,"text":"Field mode","id":"field-mode"},{"level":2,"text":"Custom mode","id":"custom-mode"},{"level":2,"text":"Related types","id":"related-types"}],"documentType":"unknown","contentOrigin":"static-doc","canonicalUrl":"/docs/adapters/write-pipeline/partitioning/","buildId":"local-1782300258906","generatedAt":"2026-06-24T11:24:18.906Z","content":"---\ntitle: Partitioning\nnavTitle: Partitioning\ndescription: How data is partitioned into Hive-style paths within the all.parquet/ directory.\n---\n\nPartitioning controls how data is organized within the `all.parquet/` directory for `full_load_append` and `append` strategies. It determines the subdirectory structure using Hive-style `key=value` paths.\n\n<Note>\n  Partitioning only applies to `full_load_append` and `append` strategies. For\n  `full_load`, partitioning is ignored.\n</Note>\n\n## Partitioning modes\n\nThe `partitioning` config value determines the mode:\n\n| Value                   | Mode      | Description                                               |\n| ----------------------- | --------- | --------------------------------------------------------- |\n| `true` (default)        | Timestamp | Partitions by write timestamp                             |\n| `false`                 | Disabled  | Flat file layout (UUID-only paths)                        |\n| `\"fieldName\"`           | Field     | Partitions by a record field's date value                 |\n| `\"field:component/...\"` | Custom    | Multi-segment partitioning with date component extraction |\n\n## Timestamp mode\n\nWhen `partitioning: true` (the default), each write is partitioned by the current timestamp. The pipeline automatically injects `load_timestamp`, `load_timestamp_year`, and `load_timestamp_month` columns into the records and schema.\n\n```\nall.parquet/year=2025/month=01/day=15/<uuid>.parquet\n```\n\nThe `partitioningFormat` controls granularity:\n\n| Format             | Example path                               |\n| ------------------ | ------------------------------------------ |\n| `\"year\"`           | `year=2025/<uuid>.parquet`                 |\n| `\"year/month\"`     | `year=2025/month=01/<uuid>.parquet`        |\n| `\"year/month/day\"` | `year=2025/month=01/day=15/<uuid>.parquet` |\n\n## Disabled mode\n\nWhen `partitioning: false`, files are placed directly in `all.parquet/` with a flat UUID-based path:\n\n```\nall.parquet/<uuid>.parquet\n```\n\n## Field mode\n\nWhen `partitioning` is a simple field name (e.g. `\"event_date\"`), the pipeline extracts the date value from each record's field and partitions accordingly:\n\n```json\n{ \"partitioning\": \"event_date\", \"partitioningFormat\": \"year/month\" }\n```\n\nFor a record with `event_date: \"2025-03-20\"`:\n\n```\nall.parquet/year=2025/month=03/<uuid>.parquet\n```\n\nRecords are grouped by their partition key — records with the same partition path are written to the same Parquet file.\n\n<Warning>\n  If a record is missing the partition field, has a null value, or contains an\n  unparseable date, the pipeline throws a `PartitionFieldError`.\n</Warning>\n\n## Custom mode\n\nCustom partitioning allows multi-segment paths with field extraction and date component parsing. The format uses `/` to separate segments and `:` to specify a date component:\n\n```json\n{ \"partitioning\": \"region/event_date:year/event_date:month\" }\n```\n\nFor a record with `region: \"eu-west-1\"` and `event_date: \"2025-03-20\"`:\n\n```\nall.parquet/region=eu-west-1/year=2025/month=03/<uuid>.parquet\n```\n\n### Segment types\n\n| Segment            | Description              | Example output     |\n| ------------------ | ------------------------ | ------------------ |\n| `fieldName`        | Raw field value          | `customer_id=acme` |\n| `fieldName:year`   | Year from ISO date       | `year=2025`        |\n| `fieldName:month`  | Month from ISO date      | `month=03`         |\n| `fieldName:day`    | Day from ISO date        | `day=20`           |\n| `fieldName:hour`   | Hour from ISO datetime   | `hour=14`          |\n| `fieldName:minute` | Minute from ISO datetime | `minute=30`        |\n| `fieldName:second` | Second from ISO datetime | `second=45`        |\n\n## Related types\n\n<InterfaceReference\n  file=\"adapters/src/write-pipeline\"\n  name=\"ResolvedPartitioning\"\n  mode=\"declaration\"\n/>\n\n<InlineReference\n  file=\"adapters/src/write-pipeline\"\n  include={[\"PartitionMode\", \"PartitionSegment\", \"PartitionFieldError\"]}\n/>\n","description":"How data is partitioned into Hive-style paths within the all.parquet/ directory.","navTitle":"Partitioning","keywords":["partitioning","partitioned","hive-style","paths","within"]}