alamb commented on code in PR #5775: URL: https://github.com/apache/arrow-datafusion/pull/5775#discussion_r1160096217
########## datafusion/substrait/src/lib.rs: ########## @@ -18,6 +18,7 @@ pub mod logical_plan; pub mod physical_plan; pub mod serializer; +mod variation_const; Review Comment: The rest of these modules are `pub` but the newly added `variation_const` is not -- is that intentional? ########## datafusion/substrait/src/variation_const.rs: ########## @@ -0,0 +1,31 @@ +// 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. + +//! Type variation constants + +pub const DEFAULT_TYPE_REF: u32 = 0; Review Comment: I am not familiar with substrait's type variations --perhaps it would help to add a reference here to the subtrait documents that describe this and what they mean ########## datafusion/substrait/tests/roundtrip_logical_plan.rs: ########## @@ -373,4 +462,52 @@ mod tests { .await?; Ok(ctx) } + + /// Cover all supported types + async fn create_all_type_context() -> Result<SessionContext> { + let ctx = SessionContext::new(); + let mut explicit_options = CsvReadOptions::new(); + let schema = Schema::new(vec![ + Field::new("a", DataType::Boolean, true), Review Comment: I would personally find this test setup easier to use and understand if the fields were named for the type (for exmaple `"bool_col"` rather than "a" The reason is that using just letters means that it is hard to understand what a particular test is testing without looking at this function ########## datafusion/substrait/tests/roundtrip_logical_plan.rs: ########## @@ -262,7 +262,79 @@ mod tests { #[tokio::test] async fn qualified_catalog_schema_table_reference() -> Result<()> { - roundtrip("SELECT * FROM datafusion.public.data;").await + roundtrip("SELECT a,b,c,d,e FROM datafusion.public.data;").await + } + + #[tokio::test] + async fn read_all_types() -> Result<()> { + let mut ctx = create_all_type_context().await?; + let df = ctx + .sql( + "select * from data where + a = TRUE AND + b = 0 AND + c = 0 AND + d = 0 AND + e = 0 AND + f = 0 AND + g = 0 AND + h = 0 AND + i = 0;", + ) + .await?; + println!("{:?}", df.clone().collect().await.unwrap()); + let plan = df.into_optimized_plan()?; + let proto = to_substrait_plan(&plan)?; + let plan2 = from_substrait_plan(&mut ctx, &proto).await?; + let plan2 = ctx.state().optimize(&plan2)?; + + println!("{plan:#?}"); + println!("{plan2:#?}"); + + let plan1str = format!("{plan:?}"); + let plan2str = format!("{plan2:?}"); + assert_eq!(plan1str, plan2str); + Ok(()) + } + + #[tokio::test] + async fn integer_type_literal() -> Result<()> { + roundtrip_all_types( + "select * from data where + a = TRUE AND + b = 0 AND + c = 0 AND + d = 0 AND + e = 0 AND + f = 0 AND + g = 0 AND + h = 0 AND + i = 0;", + ) + .await + } + + // Literal in this cases have incorrect type. This is not a good case + #[tokio::test] + async fn other_type_literal() -> Result<()> { Review Comment: I think you can use the `arrow_cast` function to get specific types -- like `arrow_cast('foo', LargeUtf8)` for example ########## datafusion/substrait/tests/roundtrip_logical_plan.rs: ########## @@ -333,6 +405,23 @@ mod tests { Ok(()) } + async fn roundtrip_all_types(sql: &str) -> Result<()> { Review Comment: Does the following syntax work? ```sql select a::boolean from data work? ``` ########## datafusion/substrait/tests/roundtrip_logical_plan.rs: ########## @@ -262,7 +262,79 @@ mod tests { #[tokio::test] async fn qualified_catalog_schema_table_reference() -> Result<()> { - roundtrip("SELECT * FROM datafusion.public.data;").await + roundtrip("SELECT a,b,c,d,e FROM datafusion.public.data;").await + } + + #[tokio::test] + async fn read_all_types() -> Result<()> { + let mut ctx = create_all_type_context().await?; + let df = ctx + .sql( + "select * from data where + a = TRUE AND + b = 0 AND + c = 0 AND + d = 0 AND + e = 0 AND + f = 0 AND + g = 0 AND + h = 0 AND + i = 0;", + ) + .await?; + println!("{:?}", df.clone().collect().await.unwrap()); + let plan = df.into_optimized_plan()?; + let proto = to_substrait_plan(&plan)?; + let plan2 = from_substrait_plan(&mut ctx, &proto).await?; + let plan2 = ctx.state().optimize(&plan2)?; + + println!("{plan:#?}"); + println!("{plan2:#?}"); + + let plan1str = format!("{plan:?}"); + let plan2str = format!("{plan2:?}"); + assert_eq!(plan1str, plan2str); + Ok(()) + } + + #[tokio::test] + async fn integer_type_literal() -> Result<()> { + roundtrip_all_types( + "select * from data where + a = TRUE AND + b = 0 AND + c = 0 AND + d = 0 AND + e = 0 AND + f = 0 AND + g = 0 AND + h = 0 AND + i = 0;", Review Comment: I wonder if there is any reason for not testing `j` and `k` (f32 and f64) as well? ########## datafusion/substrait/src/logical_plan/consumer.rs: ########## @@ -910,20 +908,196 @@ fn from_substrait_bound( } } +fn from_substrait_literal(lit: &Literal) -> Result<ScalarValue> { + let scalar_value = match &lit.literal_type { + Some(LiteralType::Boolean(b)) => ScalarValue::Boolean(Some(*b)), + Some(LiteralType::I8(n)) => match lit.type_variation_reference { + DEFAULT_TYPE_REF => ScalarValue::Int8(Some(*n as i8)), + UNSIGNED_INTEGER_TYPE_REF => ScalarValue::UInt8(Some(*n as u8)), + others => { + return Err(DataFusionError::Substrait(format!( + "Unknown type variation reference {others}", + ))); + } + }, + Some(LiteralType::I16(n)) => match lit.type_variation_reference { + DEFAULT_TYPE_REF => ScalarValue::Int16(Some(*n as i16)), + UNSIGNED_INTEGER_TYPE_REF => ScalarValue::UInt16(Some(*n as u16)), + others => { + return Err(DataFusionError::Substrait(format!( + "Unknown type variation reference {others}", + ))); + } + }, + Some(LiteralType::I32(n)) => match lit.type_variation_reference { + DEFAULT_TYPE_REF => ScalarValue::Int32(Some(*n)), + UNSIGNED_INTEGER_TYPE_REF => ScalarValue::UInt32(Some(unsafe { Review Comment: The use of unsafe here seems strange to me for two reasons: 1. It is inconsistent with Int16/UInt16 use `n as i16` / `n as u16` 2. it doesn't seem necessary --it is perfectly safe to cast i32 to u32 -- for example https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=cfd7670d0675e2353f4f8c58616b3cec I realize you just moved this code around, but I think it would be good to get rid of transmute This comment applies to Int64 as well -- 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]
