[Bug]: [Python] Type inference returns Any for attributes of NamedTuple-typed and nullable nested rows
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 55/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- python
- Lĩnh vực
- data-engineering
Hướng nghiên cứu
Start in sdks/python/apache_beam/typehints/opcodes.py, where _getattr only resolves fields when the type is a RowTypeConstraint. Reproduce with trivial_inference.infer_return_type on the Person/Address NamedTuples from the issue, then extend _getattr to accept NamedTuple classes via RowTypeConstraint.from_user_type and unwrap Optional[row] while keeping the result nullable. Done when both lambdas infer str and Optional[str] in trivial_inference_test.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
What happened?
Accessing a nested field of a schema-aware PCollection is inferred as Any. In Beam YAML this makes a common pipeline fail at construction: a MapToFields that projects a field of a Parquet struct column feeds WriteToParquet, which raises NotImplementedError: Beam logical types are not currently supported in arrow_type_compatibility (#23817) because the inferred field type is Any.
Reproducer (Parquet file with name: string, address: struct<city: string, zip: int64>):
pipeline:
type: chain
transforms:
- type: ReadFromParquet
config:
path: people_struct.parquet
- type: MapToFields
config:
language: python
fields:
name: name
city: address.city
- type: WriteToParquet
config:
path: out/people
ValueError: Error applying transform "WriteToParquet" at line 13: Beam logical types are not currently supported in arrow_type_compatibility.
The same happens with trivial_inference directly:
import typing
from apache_beam.typehints import trivial_inference
class Address(typing.NamedTuple):
city: str
class Person(typing.NamedTuple):
name: str
address: typing.Optional[Address]
trivial_inference.infer_return_type(lambda r: r.name, [Person]) # Any (expected str)
trivial_inference.infer_return_type(lambda r: r.address.city, [Person]) # Any (expected Optional[str])
Cause
opcodes._getattr (sdks/python/apache_beam/typehints/opcodes.py) resolves row.field only when the type is a RowTypeConstraint. Schema-aware PCollections are usually typed with the NamedTuple class generated for their schema (for example ReadFromParquet(as_rows=True) produces a BeamSchema_... class), and nested struct fields are Optional[Row] / Optional[NamedTuple], so both cases fall through to Any.
Resolving NamedTuple classes through RowTypeConstraint.from_user_type and unwrapping Optional[row] (keeping the result nullable) fixes inference. I have a small fix with tests in trivial_inference_test and can open a PR.
Note: with that fix the Parquet pipeline above builds, but then fails at runtime due to a separate issue where ReadFromParquet(as_rows=True) yields dicts for struct fields (filed separately).
Issue Priority
Priority: 2 (default / most bugs should be filed as P2)
Issue Components
- Component: Python SDK
- Component: Java SDK
- Component: Go SDK
- Component: Typescript SDK
- Component: IO connector
- Component: Beam YAML
- Component: Beam examples
- Component: Beam playground
- Component: Beam katas
- Component: Website
- Component: Infrastructure
- Component: Spark Runner
- Component: Flink Runner
- Component: Prism Runner
- Component: Hazelcast Jet Runner
- Component: Google Cloud Dataflow Runner
- Ngôn ngữ chính
- Java
- Star
- 8.7k
- Fork
- 4.8k
- Merge trung bình
- 2 ngày 12 giờ
- Pull request đã merge (30 ngày)
- 371
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của apache/beam
-
Release notes links wrongĐang mởawaiting triage bug P3
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 67/100
apache/beam#41197 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: [Python] WriteToJson silently rounds floats to 10 decimal placesCó thể đã có người làm @Abhi2939 đã nhận 2 ngày trước. Đang mởio P2 python yaml
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
apache/beam#41102 · 4 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
apache/beam#39624 · 2 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: PubsubIO used in batch incorrect batch cutoff sizeCó thể đã có người làm @1fanwang đã nhận 79 ngày trước. Đang mởbug io P3 pinned pubsub
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
apache/beam#28011 · 4 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
build P3 sub-task
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
[Bug] RemotingHelper.connect swaps the socket send and receive buffer configurationCó thể đã có người làm @amalsaidov đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
area/ai area/backend component/zeebe kind/task
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
spAnser/reacharound#38 ·
-
status: Ready
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
MobilityData/gtfs-validator#2254 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 89/100
Maintainer thường phản hồi trong vòng 1 ngày