csun5285 opened a new pull request, #70501:
URL: https://github.com/apache/doris/pull/70501
### What problem does this PR solve?
Issue Number: None
Related PR: #59183
Problem Summary:
CREATE TABLE LIKE prints the source table as DDL text (the SHOW CREATE TABLE
text) and parses it again. The text of a VARIANT column omits
`variant_enable_doc_mode` and `variant_enable_nested_group` when they are
false, and the parser fills every property missing from a DDL from the
`default_variant_*` session variables. So the copy depended on the session that
ran the statement:
```sql
CREATE TABLE src (id INT, v VARIANT<'a.b':INT,
PROPERTIES("variant_max_subcolumns_count"="3")>)
DUPLICATE KEY(id) DISTRIBUTED BY HASH(id) BUCKETS 1
PROPERTIES("replication_num"="1");
SET default_variant_enable_doc_mode = true;
CREATE TABLE dst LIKE src;
SHOW CREATE TABLE dst;
-- before: v variant<MATCH_NAME 'a.b':int,PROPERTIES
("variant_enable_doc_mode" = "true",
-- "variant_doc_materialization_min_rows" =
"0","variant_doc_hash_shard_count" = "64")>
-- (doc mode, the subcolumn count 3 is gone)
-- after: the SET fails; with the default session v is as in src
```
The `default_variant_*` session variables exist for the fuzzy tests only.
Fix:
1. The parser reads the `default_variant_*` session variables only when the
FE runs with `enable_debug_points = true`, which every regression pipeline and
docker test cluster sets. Otherwise, and without a session, the properties a
DDL leaves out take the built-in values (a parse without a session used its own
constants before, such as subcolumn count 0 and nested group on). It does not
use the global values either: a value set with SET GLOBAL on an older version
still loads from an image. So a DDL text, such as the one CREATE TABLE LIKE
prints and parses, creates the same column in every session.
2. The variables are invisible in SHOW VARIABLES, and SET / SET GLOBAL /
SET_VAR of them fails unless debug points are enabled. Users state VARIANT
properties in the column definition.
3. A nested group VARIANT type prints only `variant_enable_nested_group`, as
a doc mode type prints only the doc mode properties.
With debug points enabled, CREATE TABLE LIKE still follows the session; a
test that copies a VARIANT table sets the variables first, as the existing
suites do.
### Release note
The `default_variant_*` session variables
(`default_variant_max_subcolumns_count`,
`default_variant_enable_typed_paths_to_sparse`,
`default_variant_max_sparse_column_statistics_size`,
`default_variant_sparse_hash_shard_count`, `default_variant_enable_doc_mode`,
`default_variant_doc_materialization_min_rows`,
`default_variant_doc_hash_shard_count`, `default_variant_enable_nested_group`)
can no longer be set and are not shown by SHOW VARIABLES; set the properties in
the VARIANT column definition instead. A value set with SET GLOBAL before the
upgrade no longer takes effect. CREATE TABLE LIKE copies the VARIANT properties
of the source table regardless of the session.
### Check List (For Author)
- Test: Unit Test / Regression test / Manual test
- FE UT: NereidsParserTest (session values used only with debug points),
CreateTableLikeTest (LIKE under doc mode and nested group session defaults),
VariableMgrTest (SET fails, hidden, forwarded values, replay), TypeTest (nested
group text, defaults without a session), PropertyAnalyzerTest
- Regression test: variant_p0/test_variant_create_table_like
- Manual test: the DDL above on a local cluster; with
enable_debug_points = false, SET, SET GLOBAL and SET_VAR of default_variant_*
fail, SHOW VARIABLES does not list them, and with use_fuzzy_session_variable =
true the fuzzed session values do not reach new VARIANT columns
- Behavior changed: Yes. SET of the default_variant_* session variables
fails and their values are ignored unless enable_debug_points is on; SHOW
CREATE TABLE of a nested group VARIANT column prints only
variant_enable_nested_group.
- Does this need documentation: Yes, VARIANT.md lists the session variables
(doc PR to follow)
### Background
<!-- How the feature or module this PR touches works today, in two to four
plain sentences, for a reviewer who doesn't know it. Link the user doc if there
is one. Leave the problem and the fix to Problem Summary. -->
### What problem does this PR solve?
<!-- Issue Number: "close #N" if this PR resolves the issue, "#N" if it only
relates to it, "None" if there is none. A Feature needs an issue. -->
<!-- Related PR: "#N (relation)" for each PR a reviewer should know about,
such as "#123 (introduced the bug)", separated by commas. Write "None" if no
related PR is known. -->
<!-- PR Type: Bugfix, Performance, Feature, Enhancement, Refactor, Test,
Build/CI/Chore, Revert, Release/Dependency, or Other. -->
Issue Number:
Related PR:
PR Type:
Problem Summary:
<!-- Two to five sentences: the problem or need and who is affected; the
approach in one sentence; when the diff is larger than that suggests, what else
it had to handle, or that most of it is tests; and what existing users see
after an upgrade. -->
### Details
<!--
For a diff of more than about 300 changed lines, start with "- **Change
map:**": how many lines are production code, tests, generated files, and docs,
then the code in parts, each with the problem it handles and its size.
Then answer each field of your PR type on its own line, as "- **Field:**
answer", in this order:
Bugfix: Frequency, Root cause, Why existing tests missed it, Fix, Other
paths and branches
Performance: Why it was slow, Optimization, Results, Applicability and cost
Feature: Scope, Design, Usage, Default behavior, Compatibility
Enhancement: Before and after, Configs and defaults, Impact on existing
users
Refactor: Moves vs. logic changes, Behavior change, Compatibility,
Performance impact, Rollback
Test, adding tests: Scenarios, What existing tests miss, Fails when broken
Test, fixing a test: Failure, Cause, Stability evidence
Build/CI/Chore: Affected, Developer and release impact, License and
third-party, Rollback
Revert: Why not fix forward, Original author notified, Follow-up
Release/Dependency: Versions, Upstream changes, Compatibility, Rollback
Other: Why Other
"None" is a valid answer when it is true. Don't restate the diff.
-->
### Testing
<!-- The tests, suites, or commands that ran, what each shows, and where it
ran (locally or in CI). For a fix, the test that fails before it and passes
after. -->
### Notes for Reviewers
<!-- Optional; delete this section if there is nothing to say. Why each
non-obvious edit was made, what you are unsure about, and where to start
reading if Details has no Change map. -->
### Release note
<!-- One paragraph on what users will notice, or None. -->
### Check List (For Author)
<!-- Behavior changed: "No", or "Yes (see Details)" with a Behavior change
field in Details. -->
<!-- Does this need documentation: "No", or "Yes" with the
apache/doris-website PR or the plan. -->
<!-- Pre-submission status: "Ready"; "Partially verified: " and what is not
verified; or "Not ready: " and why, for a Draft PR. -->
- Behavior changed:
- Does this need documentation:
- Pre-submission status:
### AI Disclosure
<!-- Tool: the agent and model, or None. Generated: the parts it wrote
(code, tests, this description), or None. Human review: what you reviewed of
the generated parts, or "Not applicable" without AI tools. You may add "-
Prompts:" to summarize how you directed the agent. -->
- Tool:
- Generated:
- Human review:
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
