Alles aus der Excel-Datei -- und der Fund, der alles blockiert haette
Filipe: "ich will dass alles von der excel datei genommen wird.
perfektionnier das, aber wenn ich dir runter lade soll alles notiert
und angezeigt werden." Dazu eine echte Ausgabe als Vorlage.
DER SCHWERSTE FUND STECKTE VOR DEN DATEN, NICHT IN IHNEN.
Seine Ausgabe "Creator_innendaten" hat DREI Spalten, die nach Person
aussehen: "Creator*in-ID", "Creator*innen-Anmeldename" und "Agent".
`personSpaltenRaten` nahm die erste mit dem Wort "creator" darin --
die ID. Danach wurde nach einem Creator namens "700001" gesucht.
Nachgemessen an seiner echten Kopfzeile: handle = KEINE, name =
"Creator*in-ID". Diese Datei haette KEINE EINZIGE Zeile zugeordnet,
mit einem Hinweis ("steht bei keinem Creator im Feld TikTok"), der in
die voellig falsche Richtung zeigt.
Jetzt ist "Anmeldename" der Handle, eine Kennnummer ist fuer beide
Spalten ausgeschlossen, und "creator" allein reicht nicht mehr als
Namensspalte -- sonst haette weiter hinten "Neue*r LIVE-Creator*innen"
(Wert: "Nein") die Stelle uebernommen. An fuenf Kopfzeilen gemessen.
UND DANN: NICHTS FAELLT MEHR WEG.
41 Spalten in der Datei, acht werden gedeutet. Die restlichen 33 --
letzter Monat, fuenf Prozentwerte, Matches, Multi-Gast-LIVEs, Fanclub,
Graduierungs- und Stufenstatus -- wurden lautlos weggeworfen.
KEINE 33 NEUEN SPALTEN, sondern eine Zeile je Spalte mit dem NAMEN als
Schluessel. Eine abgeschriebene Spaltenliste hat in diesem Haus schon
zweimal Daten gekostet und waere beim naechsten Backstage-Update
falsch. Gegenprobe in der Pruefung: eine erfundene Spalte
("Sternenstaub pro Woche") kommt genauso durch -- es wird also keine
Liste gepflegt, die Datei entscheidet.
An SEINER echten Datei gemessen, ohne sie irgendwo hineinzuschreiben:
40 von 41 Spalten gespeichert (die 41. ist leer), Zeitraum 01.09.-
13.09. erkannt, 32 als Zahl, 8 als Text.
UND EIN MESSFEHLER, DER LEHRREICH IST: Meine erste Pruefung meldete
"zugeklappt ist die Liste 141 px hoch", im Bildschirmfoto war dort
nichts. An einem Miniaturfall nachgemessen: getBoundingClientRect,
offsetHeight, offsetParent und getClientRects liefern bei einem
<details> in BEIDEN Zustaenden identische Werte -- Chromium verbirgt
den Inhalt mit content-visibility:hidden, und das behaelt die letzte
Ausmessung. Nur checkVisibility() kann es unterscheiden. Die Messung
log, nicht die Seite.
pruef-backstage-import 160 (war 133), pruef-xlsx 75,
pruef-leistung-optik 59, pruef-leistung, pruef-css-klassen und
pruef-auskunft (46, DSGVO -- die neue Tabelle ist automatisch dabei,
weil die Auskunft ihre Liste aus PRAGMA foreign_key_list ableitet):
alle gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
@@ -3415,6 +3415,52 @@ export function db() {
|
||||
ON leistung_zeitraum (creator_id, bis DESC);
|
||||
CREATE INDEX IF NOT EXISTS idx_leistung_tag ON leistung (tag DESC);
|
||||
|
||||
/* ALLES, WAS IN DER DATEI STAND (16.09.2026)
|
||||
|
||||
Filipe: "ich will dass alles von der excel datei genommen wird
|
||||
... wenn ich dir runter lade soll alles notiert und angezeigt
|
||||
werden."
|
||||
|
||||
Seine echte Backstage-Ausgabe hat 41 SPALTEN. Die Tabelle
|
||||
darueber nimmt acht davon. Dreiunddreissig Spalten -- Zahlen
|
||||
vom letzten Monat, Prozentwerte, Matches, Multi-Gast-LIVEs,
|
||||
Fanclub, Graduierungs- und Stufenstatus -- wurden beim Einlesen
|
||||
weggeworfen, ohne dass irgendwo stand, dass es sie gab.
|
||||
|
||||
WARUM NICHT 33 WEITERE SPALTEN OBEN? Weil das eine ABGESCHRIEBENE
|
||||
LISTE waere, und die hat in diesem Haus schon zweimal Daten
|
||||
gekostet (siehe die Notiz zur Agentur-Umstellung). Sie waere
|
||||
ausserdem beim naechsten Backstage-Update falsch: TikTok
|
||||
benennt Spalten um und fuegt welche hinzu, ohne jemanden zu
|
||||
fragen.
|
||||
|
||||
EINE ZEILE JE SPALTE, und der NAME ist der Schluessel. Damit
|
||||
gilt: Was in der Datei steht, steht danach in der Datenbank --
|
||||
auch eine Spalte, die es heute noch gar nicht gibt. Nichts zu
|
||||
pflegen, nichts zu vergessen.
|
||||
|
||||
Die Spalte nr IST DIE REIHENFOLGE DER DATEI, nicht die Identitaet. Wer
|
||||
die Reihenfolge zum Schluessel machte, verwechselte zwei
|
||||
Spalten, sobald Backstage eine dazwischenschiebt.
|
||||
|
||||
BEIDES WIRD GESPEICHERT: der Text woertlich, wie er dastand
|
||||
(daraus kann man immer noch alles herleiten), und die Zahl, wenn
|
||||
es eine ist. Nur die Zahl zu behalten hiesse, "Nicht graduiert"
|
||||
und "6Std. 24Min. 7Sek." zu verlieren; nur den Text zu behalten
|
||||
hiesse, nicht rechnen zu koennen. */
|
||||
CREATE TABLE IF NOT EXISTS leistung_zeitraum_feld (
|
||||
creator_id INTEGER NOT NULL REFERENCES personen(id) ON DELETE CASCADE,
|
||||
von TEXT NOT NULL,
|
||||
bis TEXT NOT NULL,
|
||||
nr INTEGER NOT NULL,
|
||||
name TEXT NOT NULL,
|
||||
text TEXT,
|
||||
zahl REAL,
|
||||
PRIMARY KEY (creator_id, von, bis, name)
|
||||
);
|
||||
CREATE INDEX IF NOT EXISTS idx_leistung_zfeld
|
||||
ON leistung_zeitraum_feld (creator_id, von, bis, nr);
|
||||
|
||||
/* ZIELE je Creator. Aus dem 90-Tage-Plan, den es im Profil schon
|
||||
als FREITEXT gibt -- daraus wird hier eine pruefbare Groesse.
|
||||
"Mehr Reichweite" ist kein Ziel, "4 LIVE-Tage pro Woche" ist
|
||||
|
||||
Reference in New Issue
Block a user