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

Ouverte
  • Quelque chose ne va pas ?
#27,155 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
57/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
rust
Domaine
backend, databases

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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

Langage dominant
Rust
Étoiles
9.6k
Forks
2.6k
Merge moyen
3 j 4 h
PR mergées (30 j)
345

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de apache/datafusion

Toutes les issues de apache/datafusion

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.