-
[OPIK-6634] [BE] feat: add version_number filter to prompt versions list (#6806)
发布于
2026-05-21 10:37:13 +00:00 - [OPIK-6634] [BE] feat: add version_number filter to prompt versions list
Wires the existing version_number column on prompt_versions (introduced
in OPIK-6454) into the filter system so it can be used as a filter on
GET /v1/private/prompts/{id}/versions.- Add VERSION_NUMBER_QUERY_PARAM to the shared Field interface.
- Add VERSION_NUMBER to PromptVersionField as STRING_STATE_DB, matching
the column's VARCHAR storage and the operator set used by COMMIT. - Register the field-to-column mapping and allow-list the field under
FilterStrategy.PROMPT_VERSION in FilterQueryBuilder. - Extend the existing filterPromptVersionsByStringFields parameterized
test with EQUAL / NOT_EQUAL / ENDS_WITH cases for VERSION_NUMBER.
Implements OPIK-6634: [BE] Add version_number filter to prompt versions
list endpoint.Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com
- [OPIK-6634] [BE] refactor: type version_number filter as NUMBER with v-prefix normalization
Switches the version_number filter from STRING_STATE_DB to NUMBER so it
supports range operators (>, >=, <, <=) with correct numeric ordering
("v10" > "v2", not lexicographic). The on-disk value is still the
"v" VARCHAR.- Add a Field#normalizeValue(value) opt-in hook (identity by default),
overridden by PromptVersionField.VERSION_NUMBER to strip a leading
"v"/"V" so clients can send the displayed form ("v3") and not just
the raw numeric form ("3"). - Apply normalization in FiltersFactory.toValidAndDecoded after URL
decoding and before NUMBER validation. - In FilterQueryBuilder, special-case the VERSION_NUMBER column
expression to CAST(SUBSTRING(pv.version_number, 2) AS UNSIGNED) so
all NUMBER operator templates render correct integer WHERE clauses;
mask versions (NULL version_number) propagate to NULL and are
excluded from positive matches. - Replace the three STRING_STATE_DB test cases with a dedicated
filterPromptVersionsByVersionNumber parameterized test exercising
=, !=, >, >=, <, <=, and asserting both "v1" and "1" input forms.
Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com
- [OPIK-6634] [BE] fix: null-safe value comparison in filter normalization
Addresses PR review feedback: switch normalized.equals(filter.value()) to
Objects.equals(...) in FiltersFactory.toValidAndDecoded so a Field
implementation that returns null from normalizeValue() does not throw
an NPE and break validation.Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com
- [OPIK-6634] [BE] revert: keep version_number filter as STRING_STATE_DB
Revert the NUMBER + v-prefix normalization approach back to the original
STRING_STATE_DB typing. Numeric range comparisons on version_number are
not worth the extra surface area (Field#normalizeValue hook, CAST-based
non-sargable WHERE clauses, dual-form filter values); equality and
substring operators are sufficient for the current use case.- Restore PromptVersionField.VERSION_NUMBER to STRING_STATE_DB; drop the
normalizeValue override. - Remove the Field#normalizeValue default method from the interface.
- Remove the normalization block (and Objects import) from
FiltersFactory.toValidAndDecoded. - Restore the simple aliased mapping for PROMPT_VERSION_FIELDS_MAP in
FilterQueryBuilder; drop the CAST(SUBSTRING(...)) expression. - Replace the dedicated filterPromptVersionsByVersionNumber numeric test
with three string-typed cases (EQUAL, NOT_EQUAL, ENDS_WITH) in
filterPromptVersionsByStringFields.
Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com
Co-authored-by: Claude Opus 4.7 (1M context) noreply@anthropic.com
下载附件