Mich würde durchaus interessieren, wieviele der Zeilen erfolgreich/invalid/gescheitert sind. Auch (bzw. insbesondere dann) wenn ich die Output grade nicht in einem Mapper verarbeite. Kann man hier die Lazy Evaluation nicht im Schritt irgendwie umgehen (Caching?), um diese Eventlogangaben immer korrekt auszugeben?
Das ist natürlich nicht der einzige Schritt, um den es mir dabei geht. Aber eigentlich ein gutes Beispiel. Auf die Warnung würde ich sehr unterschiedlich reagieren, wenn von den insgesamt 843 Zeilen genau 1 gescheitert ist oder wenn 843 gescheitert sind.
Ja, das liegt leider an der „Lazy“ Verarbeitung der Spreadsheets. Eine möglicher Workaround wäre, den entsprechenden Step Output als input in einem CSVWriter zu verwenden. Dann gibt zumindest der CSVWriter die korrekte Anzahl (je nach printHeader Einstellung +1 Zeile für die Header Zeile) aus und du könntest ggf. den outputNumWrittenRows verwenden, um auf die Anzahl der Zeilen zu reagieren (z.B. in IF-ELSE Gruppe).
könnt ihr da nicht irgendwie in den Step schon eine Pseudo-Verarbeitung ergänzen, dass diese Angaben richtig im Eventlog gemacht werden? Die Angaben im Eventlog haben ja eigentlich NUR Mehrwert, wenn ich KEIN eigenes Reporting anhänge. Ansonsten habe ich ja mein eigenes Reporting über die Anzahl und Inhalte der Zeilen.
Ich mein, wofür gibt es die Angaben im Eventlog, wenn die nur gefüllt werden, wenn man selbst schon ein erweiteres Reporting angehangen hat.
Diese Log-Ausgabe wird an einer ziemlich zentralen Stelle erzeugt. Wenn wir da eine Pseudo-Verarbeitung einbauen würden, wäre die „Lazy“-Verarbeitung der Spreadsheets nutzlos, da dann ziemlich viele Spreadsheets mindestens einmal durchlaufen werden müssen. Der Sinn der „Lazy“ Verarbeitung ist es aber, dass nur die verwendeten Spreadsheet zu durchlaufen werden.
Da hast du schon Recht. Dieser Log-Eintrag ist an der Stelle nicht sinnvoll und eher verwirrend. Wir schauen uns das nächste Woche nochmal genauer an.
