Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

AnyScalar falls back to StringType silently; codegen should raise instead

Aperta Adatta ai principianti
  • Qualcosa non va?
#693 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
75/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python
Ambito
tooling

Direzione di ricerca

Inizia in codegen/pyspark/schema_builder.py, in _spark_for_scalar, e analizza il ramo esplicito LiteralScalar/AnyScalar e il comportamento di fallback esistente. Modifica il percorso AnyScalar in modo che sollevi un’eccezione invece di restituire _STRING_FALLBACK, quindi esegui i test codegen pertinenti e aggiungi una copertura che dimostri che AnyScalar non emette più StringType.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

overture-schema-codegen falls back to representing fields as strings in several cases, and not all of them are correct. #591 covers two of those cases; this is a third, and it needs a different fix.

Concretely, _spark_for_scalar reaches _STRING_FALLBACK by four paths:

# codegen/pyspark/schema_builder.py
def _spark_for_scalar(scalar: Scalar) -> str:
    if isinstance(scalar, (LiteralScalar, AnyScalar)):   # (1) explicit branch
        return _STRING_FALLBACK
    if scalar.base_type in SHARED_TYPE_REFS: ...
    if enum_source(scalar) is not None:                  # (2) deliberate, enums are strings
        return _STRING_FALLBACK
    return _spark_for_base(...)                          # (3,4) registry misses -> #591

Paths 3 and 4 are a scalar the registry does not know, and a registration mechanism fixes them. Path 1 is not a lookup failure: AnyScalar is the IR's faithful record that the model said Any. There is no type to register and no lookup that could have succeeded.

The proposal

Codegen should raise on AnyScalar rather than silently substitute a target type.

Targets differ in what they can honestly do with Any. Some have a genuine equivalent — an untyped object, a variant type — and can render it faithfully. Others have nothing that loose, and there the renderer is choosing a constraint on the model's behalf. StringType() is that second case: it states something the model does not, and states it invisibly, since the emitted schema looks authored.

So the decision belongs at the model, not in each renderer's default. Raising forces it into the open: either the model narrows the type, or it carries an explicit annotation saying how to project it where the target cannot express it. Either way the choice is recorded somewhere a reader can find it, which a per-renderer fallback never is.

This subsumes #591's first sub-issue (transparency/logging) for this path: with a raise, there is nothing to log.

Lingua principale
Python
Stelle
220
Fork
22
Merge medio
3g 13h
PR unite (30g)
16

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di OvertureMaps/schema

Tutte le issue di OvertureMaps/schema

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.