You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
+1 — same need here. My data arrives as nested JSON, both from REST APIs and from hierarchical files (JSON Lines). The pw.Json workaround works for accessing fields, but as the issue notes, the engine can't validate the structure or give me typed columns without manually projecting every leaf with ["a"]["b"].as_int().
What I'd want is Pydantic-style nesting — declare a pw.Schema field whose type is another pw.Schema, and have the engine validate the nested object on ingest (rejecting/flagging rows that don't match), the same way it already validates flat columns. Auto-flattening nested fields into dotted/typed columns would also cover most of my cases. This would remove a lot of boilerplate and catch malformed API/file records at the connector boundary instead of deep in the pipeline.
Activity
danghoangnhan commentedon Jun 1, 2026
+1 — same need here. My data arrives as nested JSON, both from REST APIs and from hierarchical files (JSON Lines). The
pw.Jsonworkaround works for accessing fields, but as the issue notes, the engine can't validate the structure or give me typed columns without manually projecting every leaf with["a"]["b"].as_int().What I'd want is Pydantic-style nesting — declare a
pw.Schemafield whose type is anotherpw.Schema, and have the engine validate the nested object on ingest (rejecting/flagging rows that don't match), the same way it already validates flat columns. Auto-flattening nested fields into dotted/typed columns would also cover most of my cases. This would remove a lot of boilerplate and catch malformed API/file records at the connector boundary instead of deep in the pipeline.