You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@arrow.apache.org by "Jorge (Jira)" <ji...@apache.org> on 2020/08/18 04:20:00 UTC

[jira] [Created] (ARROW-9778) [Rust] [DataFusion] Logical and physical schemas' nullability does not match in 8 out of 20 end-to-end tests

Jorge created ARROW-9778:
----------------------------

             Summary: [Rust] [DataFusion] Logical and physical schemas' nullability does not match in 8 out of 20 end-to-end tests
                 Key: ARROW-9778
                 URL: https://issues.apache.org/jira/browse/ARROW-9778
             Project: Apache Arrow
          Issue Type: Bug
          Components: Rust, Rust - DataFusion
            Reporter: Jorge


In `tests/sql.rs`, if we re-write the ```execute``` function to test the end schemas, as

```
/// Execute query and return result set as tab delimited string
fn execute(ctx: &mut ExecutionContext, sql: &str) -> Vec<String> {
    let plan = ctx.create_logical_plan(&sql).unwrap();
    let plan = ctx.optimize(&plan).unwrap();
    let physical_plan = ctx.create_physical_plan(&plan).unwrap();
    let results = ctx.collect(physical_plan.as_ref()).unwrap();
    if results.len() > 0 {
        // results must match the logical schema
        assert_eq!(plan.schema().as_ref(), results[0].schema().as_ref());
    }
    result_str(&results)
}
```

we end up with 8 tests failing, which indicates that our physical and logical plans are not aligned. In all cases, the issue is nullability: our logical plan assumes nullability = true, while our physical plan may change the nullability field.

If we do not plan to track nullability on the logical level, we could consider replacing Schema by a type that does not track nullability.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)