Skip to content

Complete Task 8: Split Cache data tags in InfluxDB 3 Enterprise #6909

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jstirnaman wants to merge 1 commit into from
+50 −28
Closed

Complete Task 8: Split Cache data tags in InfluxDB 3 Enterprise #6909

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 16 additions & 19 deletions api-docs/influxdb3/enterprise/v3/ref.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -59,24 +59,22 @@ tags:
| Querystring authentication | v1 endpoints |
<!-- ReDoc-Inject: <security-definitions> -->
x-traitTag: true
- name: Cache data
- name: Cache distinct values
description: |
Manage the in-memory cache.

#### Distinct Value Cache

The Distinct Value Cache (DVC) lets you cache distinct
values of one or more columns in a table, improving the performance of
queries that return distinct tag and field values.

The DVC is an in-memory cache that stores distinct values for specific columns
in a table. When you create an DVC, you can specify what columns' distinct
in a table. When you create a DVC, you can specify what columns' distinct
values to cache, the maximum number of distinct value combinations to cache, and
the maximum age of cached values. A DVC is associated with a table, which can
have multiple DVCs.

#### Last value cache

x-related:
- title: Manage the Distinct Value Cache
href: /influxdb3/enterprise/admin/distinct-value-cache/
- name: Cache last value
description: |
The Last Value Cache (LVC) lets you cache the most recent
values for specific fields in a table, improving the performance of queries that
return the most recent value of a field for specific series or the last N values
Expand All @@ -87,11 +85,9 @@ tags:
what fields to cache, what tags to use to identify each series, and the
number of values to cache for each unique series.
An LVC is associated with a table, which can have multiple LVCs.

#### Related guides

- [Manage the Distinct Value Cache](/influxdb3/enterprise/admin/distinct-value-cache/)
- [Manage the Last Value Cache](/influxdb3/enterprise/admin/last-value-cache/)
x-related:
- title: Manage the Last Value Cache
href: /influxdb3/enterprise/admin/last-value-cache/
- name: Database
description: Manage databases
- description: |
Expand Down Expand Up @@ -1333,7 +1329,7 @@ paths:
summary: Create distinct cache
description: Creates a distinct cache for a table.
tags:
- Cache data
- Cache distinct values
- Table
requestBody:
required: true
Expand Down Expand Up @@ -1379,7 +1375,7 @@ paths:
'404':
description: Cache not found.
tags:
- Cache data
- Cache distinct values
- Table
/api/v3/configure/last_cache:
post:
Expand All @@ -1404,7 +1400,7 @@ paths:
'409':
description: Cache already exists.
tags:
- Cache data
- Cache last value
- Table
delete:
operationId: DeleteConfigureLastCache
Expand Down Expand Up @@ -1434,7 +1430,7 @@ paths:
'404':
description: Cache not found.
tags:
- Cache data
- Cache last value
- Table
/api/v3/configure/processing_engine_trigger:
post:
Expand Down Expand Up @@ -3084,7 +3080,8 @@ x-tagGroups:
tags:
- Quick start
- Authentication
- Cache data
- Cache distinct values
- Cache last value
- Common parameters
- Response codes

Expand Down
43 changes: 34 additions & 9 deletions plans/2026-02-13-hugo-native-api-migration.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -207,22 +207,22 @@ Added clean regeneration to prevent stale files from accumulating when tags are

***

### Task 8: Apply Cache Data tag split to InfluxDB 3 Enterprise
### Task 8: Apply Cache Data tag split to InfluxDB 3 Enterprise ✅ COMPLETED

**Priority:** Medium
**Priority:** Medium | **Status:** Completed 2026-03-08

Apply the same tag split done for Core.

**Files to modify:**
**Files modified:**

- `api-docs/influxdb3/enterprise/v3/ref.yml`

**Changes:**

1. Replace "Cache data" tag with "Cache distinct values" and "Cache last value" tags
2. Update operation tag references
3. Update x-tagGroups references
4. Regenerate: `sh api-docs/generate-api-docs.sh`
1. ✅ Replaced single "Cache data" tag definition with separate "Cache distinct values" and "Cache last value" tags, each with their own `x-related` links
2. ✅ Updated 4 operation tag references: distinct_cache POST/DELETE → "Cache distinct values", last_cache POST/DELETE → "Cache last value"
3. ✅ Updated x-tagGroups to list both new tags instead of "Cache data"
4. ✅ Fixed grammar ("an DVC" → "a DVC", consistent with Core)

***

Expand All @@ -232,14 +232,24 @@ Apply the same tag split done for Core.

After the infrastructure is in place, migrate remaining products.

**Decisions (2026-03-08):**

- **Migrate v1 products:** InfluxDB OSS v1 and Enterprise v1 will be migrated to Hugo-native (not v2 products).
- **Skip v2 products:** InfluxDB OSS v2 and Cloud v2 will NOT be migrated — the effort isn't justified for legacy products approaching EOL.
- **docs-tooling dependency:** New tag structures (split tags, `x-related`, `x-traitTag`) need to be ported to the docs-tooling OpenAPI spec generation so that upstream spec regeneration preserves these customizations.

**Products:**

- [ ] cloud-dedicated (management API)
- [ ] cloud-serverless
- [ ] clustered (management API)
- [ ] cloud-v2
- [ ] oss-v2
- [ ] oss-v1
- [ ] enterprise-v1

**Skipped (not migrating):**

- ~~cloud-v2~~ — legacy, approaching EOL
- ~~oss-v2~~ — legacy, approaching EOL

**For each product:**

Expand All @@ -250,6 +260,21 @@ After the infrastructure is in place, migrate remaining products.

***

### Task 10: Port tag customizations to docs-tooling

**Priority:** High (blocks sustainable regeneration)

The tag splits, `x-related` links, and other customizations applied in Tasks 8-9 are made directly in the local spec files. These will be overwritten when specs are regenerated from `influxdata/openapi` via `getswagger.sh`. The customizations need to be ported upstream to docs-tooling so they're applied automatically during spec generation.

**Scope:**

1. Port `x-influxdata-related` link support to docs-tooling decorators
2. Port tag split logic (e.g., "Cache data" → "Cache distinct values" + "Cache last value") to docs-tooling
3. Port `x-traitTag` assignments to docs-tooling
4. Ensure `getswagger.sh` regeneration preserves all Hugo-native customizations

***

## Key Files Reference

**Hugo-Native Templates (after migration):**
Expand Down
Loading