bito-code-review[bot] commented on code in PR #43757:
URL: https://github.com/apache/superset/pull/43757#discussion_r4137933514


##########
superset/datasets/schemas.py:
##########
@@ -179,6 +195,8 @@ class DatasetPostSchema(Schema):
     normalize_columns = fields.Boolean(load_default=False)
     always_filter_main_dttm = fields.Boolean(load_default=False)
     currency_code_column = fields.String(allow_none=True, validate=Length(0, 
250))
+    partition_column = fields.String(allow_none=True, validate=Length(0, 250))
+    partition_mapped_column = fields.String(allow_none=True, 
validate=Length(0, 250))

Review Comment:
   <div>
   
   
   <div id="suggestion">
   <div id="issue"><b>POST Skips Mapping Validation</b></div>
   <div id="fix">
   
   `DatasetPostSchema` now accepts 
`partition_column`/`partition_mapped_column`, but 
`CreateDatasetCommand.validate()` never calls `validate_partition_mapping`, 
unlike the PUT path (`UpdateDatasetCommand._validate_partition_mapping`, 
update.py:316). A POST can persist a mapping PUT rejects (self-mapped or 
nonexistent columns, Jinja transform). Read-time gating keeps it inert, but 
stored state is inconsistent between the two write paths.
   </div>
   
   
   </div>
   
   
   
   
   <small><i>Code Review Run #7390a9</i></small>
   </div>
   
   ---
   Should Bito avoid suggestions like this for future reviews? (<a 
href=https://alpha.bito.ai/home/ai-agents/review-rules>Manage Rules</a>)
   - [ ] Yes, avoid them



##########
superset/connectors/sqla/partition_mapping.py:
##########
@@ -0,0 +1,350 @@
+# 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.
+"""
+Partition filter mapping.
+
+Datasets on Hadoop-family engines are commonly partitioned on a *technical*
+column -- an epoch integer, a lowercased region key -- that no analyst would
+filter on. Unless a query carries a predicate on that column the engine scans
+every partition.
+
+A dataset owner names one partition column ``p``, one business column that
+filters are mirrored from, and a value transform ``T`` (a SQL expression
+containing a ``:value`` placeholder). Superset then appends an equivalent
+predicate on ``p`` to every query, so chart authors change nothing and queries
+prune.
+
+The load-bearing assumption
+---------------------------
+Everything here reasons about ``T(col) op T(v)``, but what is emitted is
+``p op T(v)`` -- a predicate on a *physically different column*. The step from
+one to the other is::
+
+    p = T(mapped_col)   for every row in the table
+
+Superset cannot verify that; it is a property of whatever ETL populates the
+partition column. If that job lags, backfills with different logic, or writes
+the partition key in a different timezone, mirrored predicates silently drop
+real rows. The mapping is only as trustworthy as the pipeline behind it.
+"""
+
+from __future__ import annotations
+
+import logging
+import re
+from dataclasses import dataclass
+from functools import lru_cache
+
+from flask_babel import lazy_gettext as _
+
+from superset.constants import LRU_CACHE_MAX_SIZE
+from superset.exceptions import SupersetParseError
+from superset.sql.parse import SQLStatement
+
+logger = logging.getLogger(__name__)

Review Comment:
   <div>
   
   
   <div id="suggestion">
   <div id="issue"><b>Unused module logger</b></div>
   <div id="fix">
   
   `logger` is assigned at module scope but never used anywhere in this module: 
`_parse_skeleton` swallows `SupersetParseError` and returns `None` without 
logging, and no other function references it. The `import logging` exists only 
to feed this dead binding. Either log the swallowed parse failure (useful when 
owners report a mapping stuck inactive) or drop the logger and the import.
   </div>
   
   
   </div>
   
   
   
   
   <small><i>Code Review Run #7390a9</i></small>
   </div>
   
   ---
   Should Bito avoid suggestions like this for future reviews? (<a 
href=https://alpha.bito.ai/home/ai-agents/review-rules>Manage Rules</a>)
   - [ ] Yes, avoid them



##########
superset/connectors/sqla/partition_mapping.py:
##########
@@ -0,0 +1,350 @@
+# 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.
+"""
+Partition filter mapping.
+
+Datasets on Hadoop-family engines are commonly partitioned on a *technical*
+column -- an epoch integer, a lowercased region key -- that no analyst would
+filter on. Unless a query carries a predicate on that column the engine scans
+every partition.
+
+A dataset owner names one partition column ``p``, one business column that
+filters are mirrored from, and a value transform ``T`` (a SQL expression
+containing a ``:value`` placeholder). Superset then appends an equivalent
+predicate on ``p`` to every query, so chart authors change nothing and queries
+prune.
+
+The load-bearing assumption
+---------------------------
+Everything here reasons about ``T(col) op T(v)``, but what is emitted is
+``p op T(v)`` -- a predicate on a *physically different column*. The step from
+one to the other is::
+
+    p = T(mapped_col)   for every row in the table
+
+Superset cannot verify that; it is a property of whatever ETL populates the
+partition column. If that job lags, backfills with different logic, or writes
+the partition key in a different timezone, mirrored predicates silently drop
+real rows. The mapping is only as trustworthy as the pipeline behind it.
+"""
+
+from __future__ import annotations
+
+import logging
+import re
+from dataclasses import dataclass
+from functools import lru_cache
+
+from flask_babel import lazy_gettext as _
+
+from superset.constants import LRU_CACHE_MAX_SIZE
+from superset.exceptions import SupersetParseError
+from superset.sql.parse import SQLStatement
+
+logger = logging.getLogger(__name__)
+
+FEATURE_FLAG = "PARTITION_FILTER_MAPPING"

Review Comment:
   <div>
   
   
   <div id="suggestion">
   <div id="issue"><b>Unused FEATURE_FLAG constant</b></div>
   <div id="fix">
   
   `FEATURE_FLAG = "PARTITION_FILTER_MAPPING"` is defined but never referenced 
in this module or elsewhere (`grep -rn FEATURE_FLAG` finds only this line and 
test config). The consumer `UpdateDatasetCommand._validate_partition_mapping` 
re-hardcodes the string literal `"PARTITION_FILTER_MAPPING"` in 
`is_feature_enabled(...)`, so the constant fails its only purpose: keeping the 
flag name in one place. Either use it at the call site or delete it.
   </div>
   
   
   </div>
   
   
   
   
   <small><i>Code Review Run #7390a9</i></small>
   </div>
   
   ---
   Should Bito avoid suggestions like this for future reviews? (<a 
href=https://alpha.bito.ai/home/ai-agents/review-rules>Manage Rules</a>)
   - [ ] Yes, avoid them



-- 
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]

Reply via email to