Testprogramm zur 3c

Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.

Testprogramm zur 3c
Ich hab mir grad mal ein kleines Programm geschrieben, das nachschaut, ob die richtigen Einträge es auch in die Datenbank geschafft haben.
Aufruf analog zum csvimporter (und mit der gleichen CSV-Datei natürlich).

http://wwwcip.cs.fau.de/~simagrop/csvtester.tar.gz

…und unbedingt auch mit kaputten CSV-Dateien (wie die vom Jo aus der Newsgroup) ausprobieren… :slight_smile:


So, ich hab das Programm noch ein bisschen verändert, und hätte hier noch ein paar Test-CSVs:
http://wwwcip.cs.fau.de/~simagrop/csv/

Noch eine kleine Anmerkung:
Die Meldung über inkonsistente Daten bedeutet, dass die Daten in der Datenbank denen der aktuellen Zeile widersprechen. Falls beim Eintragen die falschen Daten in der DB gelandet sind, stimmt die Zeilenangabe in der Meldung also natürlich nicht.


Originaltext auf Verlangen des ehemaligen Benutzers gelöscht.

Sinngemäßer Inhalt: Findets schade, dass es closed-source ist, will nicht das bereits kompilierte Programm zu starten, hätte gern den Quelltext.


Hallo,

ich würde mal behaupten, dass 90 % des Aufgabencodes im Code dieses Testprogramms drinstecken :wink:

cu
Ford Prefect


Originaltext auf Verlangen des ehemaligen Benutzers gelöscht.

Sinngemäßer Inhalt: Argumente um den Quelltext trotzdem zu kriegen.


Genau so ist es – das Ganze ist eine leicht veränderte Version von meiner Lösung, und wenn ich die veröffentliche, beschwert sich unter Garantie jemand… :wink:


Cooles Teil, vielen Dank!

Allerdings habe ich Probleme beim Testen der Datei [m]10.1.csv[/m]: Dein Test sagt mir, dass ein paar Daten in Zeile 1 nicht importiert wurden, obwohl sie definitiv in der Datenbank drin sind.
Ich habe herausgefunden, dass das am etwas ungluecklich gewaehlten Liedtitel It’'s Ok liegt - da bekommt PostgreSQL wegen der Hochkommas Probleme beim Parsen. Ich habe leider noch keinen Weg gefunden, wie man das beheben kann.


Hallo,

wenn du den String mit " abschließt, er aber selbst ein " enthält, musst du dieses Zeichen entsprechend escapen. Das geht mit .

Anstelle von \ im Text musst du also \ schreiben, anstelle von " dann ". Ich weiss nicht, welche anderen Zeichen noch escaped werden müssen.

Schwer zu finden im PostgreSQL-Handbuch: http://www.postgresql.org/files/documentation/books/pghandbuch/html/arrays.html#AEN5028

cu
Ford Prefect


Ich hab mal noch eine zweite Version mit ge-escape-ten Strings gemacht…
Alles unter http://wwwcip.cs.fau.de/~simagrop/csv/

…und von Anfang an TableWriter zu verwenden wäre gar keine so schlechte Idee gewesen…


http://stderr.org/doc/libpqxx-dev/html/Reference/a00378.html


Mach man nun eigentlich

INSERT INTO … ‘Hallo’;

oder

INSERT INTO … “Hallo”;

Und was genau macht eigentlich eol.csv?
Soll die Datei überhaupt einträge machen?
Weil so wie ich die Datei sehe, sind dort nur “falsche” Zeilen drin


Strings kommen in ‚Single-Quotes‘ (oder in den TableWriter :slight_smile: )

eol = end of line: es sind tatsächlich nur zwei Varianten eines falschen Zeilenendes. Bei der einen fehlt das Semikolon am Ende, bei der anderen kommt nach dem letzten Strichpunkt noch ein bisschen Müll.


Aber das Semikolon am Ende kann doch sein, oder nicht?

Deswegen ist der Eintrag doch trotzdem gültig, das Zeilenende symbolisiert doch das Ende des Datensatzes.


Laut Angabe ist am Ende ein Semikolon.
Was man machen soll, wenn keines da ist, ist nicht so ganz klar (jedenfalls nicht bis zum Semikolon in der nächsten Zeile lesen) – aber angeblich dürfen wir eh davon ausgehen, dass nur mit korrekt formatierten Dateien getestet wird.


Danke für den Hinweis,

Aber z.B. ist doch 10.1. It’'s Ok ist der CSV-Datei bereits escaped, oder etwa nicht?


Also ich steck die Daten mit dem Tablewirter in die Datenbank rein und escape NIX.

Wenn der Liedtitel eben It’'s Ok heißen soll, bitte… So steht er bei mir drin!


Vermutlich ja – wobei mir das Ganze eh irgendwie ziemlich unglücklich vorkommt…
Entweder es ist escaped, dann muss ich in der Aufgabenstellung ausdrücklich drauf hinweisen (bzw. das spezielle CSV-Format ordentlich definieren; und die Leute, die mit dem tablewriter arbeiten, schauen erstmal blöd), oder ich mache es realistisch und muss halt auf solche Dinge aufpassen (SQL Injection olé…)

…bei mir heißt’s jetzt jedenfalls It’'s Ok…


Ich mein, ich bei mir die SQL-Anweisungen selber zusammen, ich hab’ das Problem auch mal in der NG geschildert, Beitrag von gerade eben, kannst dort ja einmal auf Antworten checken, fragen kostet ja nix und die Aufgabenstellung sollte doch etwas genauer sein.


erstmal danke fuer die tests aber mal ne kurze frage:
was soll denn bei “incons.csv” rauskommen?
ich habe am ende in allen tabellen nur einen eintrag, aber ich werde aus der ausgabe des csvtester nicht ganz schlau…