fix(frontend): support human-readable datetime strings in MO_TS table hint - #24629
Conversation
… hint
When `{MO_TS = '2024-01-01 00:00:00'}` was used, it only accepted
the internal debug timestamp format (`PhysicalTime-LogicalTime`).
Now it tries to parse human-readable datetime strings first,
falling back to the debug format if that fails.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
## What type of PR is this? - [ ] API-change - [x] BUG - [ ] Improvement - [ ] Documentation - [ ] Feature - [x] Test and CI - [ ] Code Refactoring ## Which issue(s) this PR fixes: issue matrixorigin#24122 issue matrixorigin#21685 ## What this PR does / why we need it: Adds BVT coverage for two existing features: - SQL Task string literal preservation: verifies string literals in `WHEN` gate conditions and SQL task bodies are preserved in `mo_task.sql_task` and execute with the expected semantics. - `ALTER USER ... LOCK/UNLOCK`: verifies lock/unlock status transitions for sys tenant users and normal tenant users. - Account restore coverage for normal tenants: verifies locked normal tenant users and normal tenant admin users restore to the snapshot lock status.
use cuVS C++ library for Kmeans, Cagra, Ivfflat, brute force, ivfpq integrate pairwise distance to sql function L2Distance, InnerProduct,...etc. GPU Brute force index for CentriodX JOIN Parameter "gpu_mode" with valid values [0|1]. With CPU build, default value is 0. Wtih GPU build, default value is 1. Approved by: @ouyuanning, @aunjgr, @heni02, @fengttt, @gouhongshen, @LeftHandCold, @iamlinjunhong, @XuPeng-SH
补充函数 ``` JSON_ARRAY JSON_OBJECT JSON_TYPE JSON_VALID JSON_LENGTH JSON_KEYS JSON_PRETTY JSON_SCHEMA_VALID JSON_SCHEMA_VALID_REPORT JSON_VALUE ``` Approved by: @aunjgr, @heni02, @XuPeng-SH
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
@fengttt @iamlinjunhong @LeftHandCold @aunjgr @ouyuanning Please review this PR. |
aunjgr
left a comment
There was a problem hiding this comment.
Clean fix. The human-readable datetime path is added before the debug-format fallback, matching the ATTIMESTAMPTIME branch's pattern:
time.Parse("2006-01-02 15:04:05.999999999", ...)first → producesPhysicalTimedirectly- Falls back to
timestamp.ParseTimestamp(...)forPhysicalTime-LogicalTimedebug format tsNano <= 0correctly rejects sub-epoch timestamps (physical_time=0 is an invalid sentinel in TAE)
Error propagation via named-return err is correct in both branches. LGTM.
Merge Queue Status
This pull request spent 1 hour 15 minutes 24 seconds in the queue, including 1 hour 13 minutes 45 seconds running CI. Required conditions to merge
|
What type of PR is this?
Which issue(s) this PR fixes:
issue #24554
What this PR does / why we need it:
When
{MO_TS = '2024-01-01 00:00:00'}was used, it only accepted the internal debug timestamp format (PhysicalTime-LogicalTime), causinginvalid debug timestamp stringerrors for human-readable datetime strings. This PR makes the MO_TS hint try to parse human-readable datetime strings first, falling back to the debug format if parsing fails, matching the behavior of the existing{TIMESTAMP = '...'}hint.Special notes for your reviewer:
The change is isolated to the
ATMOTIMESTAMPstring-literal branch inResolveTsHint(). It reuses the sametime.Parsepattern already present in theATTIMESTAMPTIMEbranch.🤖 Generated with Claude Code