Skip to content

Conversation

@ndenev
Copy link
Owner

@ndenev ndenev commented Jan 19, 2026

Summary

  • Implements table-aware JSON column detection so resource-specific JSON columns (like containers in podmetrics, usage in nodemetrics) are correctly recognized for dot-notation and array expansion syntax
  • Adds ColumnDef::json() constructor and marks 15+ core resource fields as JSON arrays/objects
  • Extracts table names from SQL queries to look up table-specific JSON columns from the registry

Problem

Previously, SELECT containers[] FROM podmetrics didn't work because containers wasn't in the hardcoded DEFAULT_JSON_OBJECT_COLUMNS list. Adding it to the hardcoded list would be incorrect since another resource could have a containers column that's a string.

Solution

Table-aware detection:

  1. Extract table names from FROM/JOIN clauses
  2. Look up each table's schema in the registry
  3. Collect columns marked with is_json_object: true
  4. Merge with defaults and pass to JSON path preprocessor

Test plan

  • cargo test - 314 tests pass
  • cargo clippy - no warnings
  • Manual test: SELECT containers[] FROM podmetrics
  • Manual test: SELECT containers[].name FROM podmetrics
  • Manual test: SELECT usage.cpu FROM nodemetrics

Previously, JSON path syntax (e.g., `containers[]`, `usage.cpu`) only worked
for columns in the hardcoded DEFAULT_JSON_OBJECT_COLUMNS list (spec, status,
labels, annotations, data, owner_references). This meant resource-specific
JSON columns like `containers` in podmetrics weren't recognized.

This change implements table-aware JSON column detection:

- Add `ColumnDef::json()` constructor to explicitly mark JSON array/object columns
- Update `get_core_resource_fields()` to use `json()` for 15+ array/object fields:
  rules, subjects, containers, usage, subsets, involved_object, source, etc.
- Add `ResourceRegistry::get_json_columns()` and `get_json_columns_for_tables()`
- Add `extract_table_names()` to parse FROM/JOIN clauses from SQL
- Add `preprocess_sql_with_registry()` for table-aware preprocessing
- Update `execute_sql()` to use the new preprocessing function

Now queries like `SELECT containers[] FROM podmetrics` work correctly because:
1. Table name "podmetrics" is extracted from the query
2. Registry lookup finds containers has is_json_object=true
3. The `[]` syntax is recognized and converted to UNNEST(json_get_array(...))

This approach is table-aware - if another resource had a `containers` column
that was a string, it wouldn't be incorrectly treated as JSON.
@claude
Copy link

claude bot commented Jan 19, 2026

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

@ndenev ndenev merged commit eb1095a into master Jan 19, 2026
8 checks passed
@ndenev ndenev deleted the feat/table-aware-json-columns branch January 19, 2026 15:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants