github-actions[bot] commented on code in PR #66677: URL: https://github.com/apache/doris/pull/66677#discussion_r3765920317
########## regression-test/suites/external_table_p0/jdbc/test_jdbc_stale_schema_precision.groovy: ########## @@ -0,0 +1,307 @@ +// Licensed to the Apache Software Foundation (ASF) under one +// or more contributor license agreements. See the NOTICE file +// distributed with this work for additional information +// regarding copyright ownership. The ASF licenses this file +// to you under the Apache License, Version 2.0 (the +// "License"); you may not use this file except in compliance +// with the License. You may obtain a copy of the License at +// +// http://www.apache.org/licenses/LICENSE-2.0 +// +// Unless required by applicable law or agreed to in writing, +// software distributed under the License is distributed on an +// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +// KIND, either express or implied. See the License for the +// specific language governing permissions and limitations +// under the License. + +import java.sql.Connection +import java.sql.DriverManager + +// A JDBC catalog caches the remote column definition. When the remote DDL widens a column's +// precision, that cache keeps reporting the narrower one until it is refreshed, so the planner +// sees source and target as the same type and emits no narrowing cast. The value scanned out of +// the remote database still carries its full precision, and nothing downstream re-normalizes it. +// +// For a DATETIMEV2 key column that is not cosmetic: sub-second digits live in the same 64-bit word +// the storage layer encodes as a key, so two rows the column claims are equal become two distinct +// keys and a unique table stops deduplicating them. +// +// These cases drive the remote DDL directly (the catalog is read-only) to put the cache and the +// remote schema out of step on purpose, then assert that what lands in Doris still respects the +// target column's declared type. +suite("test_jdbc_stale_schema_precision", "p0,external") { Review Comment: [P2] Exercise both changed JDBC reader publishers deterministically This suite never sets `enable_file_scanner_v2`, which fuzzy-session initialization chooses once for the reused FE connection. Each run therefore exercises either the changed legacy `JdbcJniReader` publisher or the independently changed V2 publisher, never both, and the related BE tests do not assert `columns_nullable`. Please run the stale-nullability rejection and refreshed-success cases under explicit `false` and `true` settings (the same deliberately stale catalog state can be reused) so both wire payloads are covered on every run. -- 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]
