`Expr::Not` and `PhysicalExpr::NotExpr` have different metadata propagation rules

Aberta
#27,155 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
57/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
rust
Domínio
backend, databases

Direção de pesquisa

The reproduction identifies Expr::Not::to_field and physical NotExpr::return_field as the paths with different metadata results. Read those implementations and nearby expression metadata tests first; the issue leaves open which behavior is correct. Decide on consistent propagation rules, add a regression test for the chosen behavior, and verify logical and physical fields agree.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

bug
Describe the bug

The logical an physical representations of NOT propagate metadata differently.

I'm actually not sure which one is more correct...some metadata uses like "sensor" or "where this value came from" probably are not lying after a NOT operation; however, it's also a little like a function call which would discard its output metadata.

To Reproduce
#[test]
fn not_metadata_differs_between_logical_and_physical() -> Result<()> {
    let schema = Schema::new(vec![Field::new("flag", DataType::Boolean, false)]);
    let df_schema = DFSchema::try_from(schema.clone())?;

    let metadata = FieldMetadata::from(HashMap::from([(
        "source".to_string(),
        "input".to_string(),
    )]));

    let expr = Expr::Not(Box::new(
        col("flag").alias_with_metadata("flag", Some(metadata)),
    ));

    let logical_field = expr.to_field(&df_schema)?.1;
    let physical_expr = create_physical_expr(
        &expr,
        &df_schema,
        &ExecutionProps::new(),
        &PhysicalPlanningContext::default(),
    )?;
    let physical_field = physical_expr.return_field(&schema)?;

    // Logical NOT creates a metadata-free Boolean field.
    assert_eq!(logical_field.metadata().get("source"), None);

    // Physical NotExpr forwards its child's field metadata.
    assert_eq!(
        physical_field.metadata().get("source").map(String::as_str),
        Some("input")
    );

    Ok(())
}
Expected behavior

I'd expect the result to match

Additional context

No response

Willingness to contribute

I would like to contribute a fix for this bug, but request guidance from the DataFusion community

Linguagem predominante
Rust
Estrelas
9.6k
Forks
2.6k
Merge médio
3d 4h
PRs com merge (30d)
345

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de apache/datafusion

Todas as issues de apache/datafusion

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.