-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[refactor](metrics) Complete metrics for some operators #42992
Conversation
Thank you for your contribution to Apache Doris. Since 2024-03-18, the Document has been moved to doris-website. |
run buildall |
1 similar comment
run buildall |
clang-tidy review says "All clean, LGTM! 👍" |
1 similar comment
clang-tidy review says "All clean, LGTM! 👍" |
88ff0e6
to
906338a
Compare
run buildall |
clang-tidy review says "All clean, LGTM! 👍" |
run buildall |
clang-tidy review says "All clean, LGTM! 👍" |
run buildall |
clang-tidy review says "All clean, LGTM! 👍" |
PR approved by at least one committer and no changes requested. |
PR approved by anyone and no changes requested. |
run buildall |
clang-tidy review says "All clean, LGTM! 👍" |
TeamCity be ut coverage result: |
PR approved by at least one committer and no changes requested. |
### What problem does this PR solve? <!-- You need to clearly describe your PR in this part: 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 this function was added. 4. Which codes were refactored and why this part of the code was refactored. 5. Which functions were optimized and what is the difference before and after the optimization. The description of the PR needs to enable reviewers to quickly and clearly understand the logic of the code modification. --> <!-- If there are related issues, please fill in the issue number. - If you want the issue to be closed after the PR is merged, please use "close #12345". Otherwise, use "ref #12345" --> Issue Number: close #xxx <!-- If this PR is followup a preivous PR, for example, fix the bug that introduced by a related PR, link the PR here --> Related PR: #xxx Problem Summary: ### Check List (For Committer) - Test <!-- At least one of them must be included. --> - [ ] Regression test - [ ] Unit Test - [ ] Manual test (add detailed scripts or steps below) - [ ] No need to test or manual test. Explain why: - [ ] This is a refactor/code format and no logic has been changed. - [ ] Previous test can cover this change. - [ ] No colde files have been changed. - [ ] Other reason <!-- Add your reason? --> - Behavior changed: - [x] No. - [ ] Yes. <!-- Explain the behavior change --> - Does this need documentation? - [x] No. - [ ] Yes. <!-- Add document PR link here. eg: apache/doris-website#1214 --> - Release note <!-- bugfix, feat, behavior changed need a release note --> <!-- Add one line release note for this PR. --> None ### Check List (For Reviewer who merge this PR) - [ ] Confirm the release note - [ ] Confirm test cases - [ ] Confirm document - [ ] Add branch pick label <!-- Add branch pick label that this PR should merge into -->
Hi, I am working on a patch to fix #42406. Initially I came across the issue on Doris 2.1.6 so I based my work on branch-2.1. I added some tests in be/test/vec/data_types/serde/data_type_serde_arrow_test.cpp but I can't find the file on master branch. It turns out the file was removed in this pull request. It seems odd to me as the test file is irrelevant to this pr. Is there a particular reason to remove it? Thanks. |
Hi @0xderek , sorry for this late reply. I removed this file because I found a function |
Hi @Gabriel39 Glad to hear from you. I think the function The reason I care so much about the test is that I have a use case which heavily depends on stream loading in arrow format. Without this test file, serialization / deserialization for data in arrow format was left completely untested. Not to mention the coverage was rather low in the first place. With that being said, I am glad to know that test refactoring is in progress. Thank you for your effort. |
Proposed changes
Issue Number: close #xxx