Skip to content

branch-4.0: [fix](parse) No longer throws exceptions when parse datetime failed in from_olap_string #63035#63077

Open
zclllyybb wants to merge 1 commit intoapache:branch-4.0from
zclllyybb:backport-63035-4.0
Open

branch-4.0: [fix](parse) No longer throws exceptions when parse datetime failed in from_olap_string #63035#63077
zclllyybb wants to merge 1 commit intoapache:branch-4.0from
zclllyybb:backport-63035-4.0

Conversation

@zclllyybb
Copy link
Copy Markdown
Contributor

pick #63035

…n from_olap_string

### What problem does this PR solve?

Issue Number: None

Related PR: apache#63035

Problem Summary: Backport apache#63035 to branch-4.0. SerDe from_olap_string handled invalid datelike strings inconsistently: DateV2 and DateTimeV2 filled type minimums while DateV1 and DateTimeV1 returned errors. This change makes DateV1 and DateTimeV1 fall back to datelike minimums and documents the existing DateV2 and DateTimeV2 fallback behavior.

### Release note

None

### Check List (For Author)

- Test: Unit Test
    - ./run-be-ut.sh --run --filter=OlapTypeTest.*
- Behavior changed: Yes. Invalid DateV1/DateTimeV1 values passed through from_olap_string now produce the datelike minimum, matching DateV2/DateTimeV2.
- Does this need documentation: No
Copilot AI review requested due to automatic review settings May 8, 2026 08:54
@hello-stephen
Copy link
Copy Markdown
Contributor

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

  1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
  2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
  3. What features were added. Why was this function added?
  4. Which code was refactored and why was this part of the code refactored?
  5. Which functions were optimized and what is the difference before and after the optimization?

@zclllyybb zclllyybb changed the title [fix](parse) No longer throws exceptions when parse datetime failed in from_olap_string branch-4.0: [fix](parse) No longer throws exceptions when parse datetime failed in from_olap_string #63035 May 8, 2026
@zclllyybb
Copy link
Copy Markdown
Contributor Author

run buildall

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR aligns OLAP-string deserialization behavior for datelike types by avoiding errors/exceptions on parse failure and instead populating a type-specific minimum/default value, improving robustness when encountering legacy or placeholder zonemap values.

Changes:

  • Make TYPE_DATE/TYPE_DATETIME from_olap_string() fall back to VecDateTimeValue::FIRST_DAY instead of returning InvalidArgument.
  • Document and preserve the existing fallback behavior for DATEV2/DATETIMEV2 (MIN_DATE_V2 / MIN_DATETIME_V2) on parse failure.
  • Add a BE unit test asserting default fallback behavior on invalid OLAP strings for all datelike variants.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File Description
be/test/olap/olap_type_test.cpp Adds a regression test validating datelike from_olap_string() parse-failure defaults.
be/src/vec/data_types/serde/data_type_datev2_serde.cpp Clarifies parse-failure fallback to MIN_DATE_V2 in from_olap_string().
be/src/vec/data_types/serde/data_type_datetimev2_serde.cpp Clarifies parse-failure fallback to MIN_DATETIME_V2 in from_olap_string().
be/src/vec/data_types/serde/data_type_date_or_datetime_serde.cpp Changes DATE/DATETIME from_olap_string() to fall back to FIRST_DAY instead of erroring.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

const std::string& input,
const vectorized::Field& expected_field) {
vectorized::Field field;
vectorized::DataTypeSerDe::FormatOptions options;
Comment on lines 405 to 409
// set false to `is_strict`, it will not set error code cuz we dont need then speed up the process.
// then we rely on return value to check success.
// return value only represent OK or InvalidArgument for other error(like InternalError) in parser, MUST throw
// Exception!
if (!CastToDateOrDatetime::from_string_non_strict_mode<IsDatetime>(
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.

3 participants