mirror of
https://github.com/volcengine/OpenViking.git
synced 2026-09-30 17:28:07 +08:00
dingbenandTRAE CLI
3cd1d4e9ac
* fix(vikingdb): normalize all date_time range filters in API key client OpenViking compiles TimeRange down to the internal `range` DSL, but the commercial VikingDB data plane (Bearer API-key auth) expects `time_range` for date_time fields and `range` only for numeric fields. The API-key client does not run the local engine's filter conversion, so `range` nodes on date_time fields were sent verbatim and mis-handled. Normalize `range` -> `time_range` for every schema date_time field by reusing the canonical VALID_TIME_FIELDS constant, covering both `created_at` and `updated_at` instead of hardcoding a single field name. Numeric `range` nodes and nested boolean filter structure are preserved, and filters already emitted as `time_range` pass through unchanged. Only the request body `filter` is rewritten; upsert/update data is untouched. Add regression tests covering the converted created_at/updated_at date filters, an unchanged numeric filter, and time_range idempotency. Co-authored-by: TRAE CLI <noreply@bytedance.com> * fix(vikingdb): normalize date_time filters in AK/SK client The API-key client already rewrites `range` filter nodes on date_time fields to VikingDB's `time_range` operator, but the AK/SK-signed `VolcengineCollection` shares the same commercial data-plane endpoints and had the identical latent bug: `TimeRange` expressions compile down to the internal `range` DSL, which the commercial API only accepts for numeric fields. Mirror the API-key fix in `VolcengineCollection._data_post` so both auth modes normalize `range` -> `time_range` for `created_at`/`updated_at` while leaving numeric `range` nodes untouched. Add AK/SK coverage for both date_time fields and for idempotency of already-`time_range` input. Co-authored-by: TRAE CLI <noreply@bytedance.com> --------- Co-authored-by: TRAE CLI <noreply@bytedance.com>