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

Allow multiple `do_node_execute` adapters

Aperta
  • Qualcosa non va?
#1,388 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
30/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
python
Ambito
data-engineering

Direzione di ricerca

Inizia tracciando l’istanziazione del driver Hamilton e la gestione degli adapter che implementano l’hook do_node_execute. Il lavoro è completato quando è possibile fornire più adapter di questo tipo con un ordine di wrapping definito e il comportamento è coperto da test e documentato per gli utenti.

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

Descrizione

caching enhancement plugin

Is your feature request related to a problem? Please describe.
I am trying to use Hamilton caches with a custom implementation of the GracefulErrorAdapter already available in Hamilton. Since both caching and the error handling adapter use the do_node_execute hook, driver instantiation fails when specifying a cache and the error handling adapter.

Describe the solution you'd like
I would like to be able to instantiate a Hamilton driver with more than one adapter using the do_node_execute hook. The behavior of the driver would then depend on some precedence for the order in which the adapters wrap the node. This precedence would likely be determined by considerations within Hamilton, but should be fairly obvious to the user.

Describe alternatives you've considered

Subclassing the base Hamilton driver myself and implementing my custom error adapter within this subclass.
Not using caching
  • - Makes my pipelines slower on reruns, no benefit from code versioning etc.
  • + No maintenance cost or complexity for metadata store or result store.
Not using an error handling adapter
  • - Any failure within one node in the pipeline means no results for any nodes. This is awful when we have nodes which will fail under certain conditions but should not cause the pipeline to fail.
  • - Achieving "graceful" error handling otherwise (i.e., error checking in every node) increases code complexity with little gain.

Additional context

Less relevant to the feature request:
The primary change my GracefulErrorAdapter implementation makes from the Hamilton implementation is passing context about the error forward instead of just a sentinel value. I'm making a Hamilton pipeline that has lots of finnicky computer vision code within which is usually not worth writing complex error checking for. I wouldn't mind contributing this adapter to the project so that I can get more eyes on it.

Lingua principale
Jupyter Notebook
Stelle
2.6k
Fork
218
Merge medio
2g 13h
PR unite (30g)
18

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 apache/hamilton

Tutte le issue di apache/hamilton

Issue simili

Altre issue su Data Engineering

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.