SQL-DB-Dump lesen und konverieren (Projekte)

[thread]18963[/thread]

SQL-DB-Dump lesen und konverieren

Leser: 15

Articles: hide open all | hide show old branches

+19 replies
topeg

2014-03-14 02:28

User since
2006-07-10
2611 Artikel
BenutzerIn

Ich stand vor kurzem vor dem Problem einen ~800Mb großen SQL Dump nach bestimmten Daten zu durchsuchen. Eine Möglichkeit wäre es natürlich gewesen ihn in eine DB einzuspielen. Aber ich war mir nicht sicher ob der SQL-Dump :
1. vollständig und Syntaktisch korrekt war,
2. in ihm nicht irgend etwas schlimmes stand und
3. Ob das auch Rechtlich OK gewesen wäre.

So setze ich mich daran um einen sehr einfachen SQL Parser zu schreiben, der mir die CREATE und INSERT Statements lesen konnte.

Anhang also mein Ergebnis. Anders als meine persönliche Version (Ich habe nach zwei speziellen Tabellen gefiltert) erzeugt diese für jede im SQL-Dump vorhandene Tabelle eine CSV mit den Daten. Es wird für jede Tabelle ein CREATE und INSERT Statements erwartet. Die Daten sind so formatiert das Text::CSV sie lesen kann. Sie sind nicht zwangsläufig menschenlesbar formatiert.

Das Scipt besteht aus zwei Teilen. Einem Modul welches das Parsen übernimmt und einem kleinen Frontend, das Die geparsten Daten als CSV ablegt.

Zu beachten ist, das der Parser Rudimentär ist. Er kann die reine Synatx parsen. Er kann also Klammern, Kommata, Strings, Kommentare sowie Schlüsselworte Finden, Zuordnen und Gruppieren. Er hat aber keinerlei weitergehende Funktionalitäten. Die erzeugten Strukturen werden nicht bewertet und weiterreichende Zugehörigkeiten werden nicht erzeugt. (z.B bei Befehlen, die aus zwei Worten bestehen)
Nur INSERT und CREATE sind als "Befehle" gekennzeichnet. Das war alles was ich brauchte.

Der Parser arbeitet nicht rekursiv, da ich dabei in "Deep Rekursion" Warnungen gelaufen bin. Ist eine SQL-Zeile gelesen worden, so werden die vorher definierten Handler ausgeführt und der Datensatz and die Funktionen übergeben.

Das ganze steht unter einer nimm es oder lass es sein Lizenz. Ich übernehme keine Verantwortung, wenn jemand damit etwas kaputt macht.
Anhänge

text/plain
281 lines
sqldump_to_csv.pl
- +16 replies
- rosti
  
  2014-03-14 07:46
  
  User since
  2011-03-19
  3472 Artikel
  BenutzerIn
  
  Quote
  Anhang also mein Ergebnis. Anders als meine persönliche Version (Ich habe nach zwei speziellen Tabellen gefiltert) erzeugt diese für jede im SQL-Dump vorhandene Tabelle eine CSV mit den Daten. Es wird für jede Tabelle ein CREATE und INSERT Statements erwartet. Die Daten sind so formatiert das CPAN:Text::CSV sie lesen kann. Sie sind nicht zwangsläufig menschenlesbar formatiert.
  
  Warum machst Du das so umständlich über eine CSV-Datei mit all den Nachteilen, die ein solches Format mit sich bringt? Ich programmiere schon seit Jahren Serializer, die sowas machen, die können das auch remote per HTTP; hier kommt die Frage der Bandbreite ins Spiel und so heißt meine Lösung NICHT CSV, weder für die Übertragung noch für die Speicherung der Dump-Sequenz auf der Lokalen Festplatte und durchsuchbar sind derartig erzeugte Dumps auch.
  
  --Rosti
  - renee
    
    2014-03-14 09:36
    
    User since
    2003-08-04
    14371 Artikel
    ModeratorIn
    
    CSV hat den Vorteil, dass man die Dateien mal schnell in nem Editor aufmachen und anschauen kann. So kann ich mir Informationen auch auf Maschinen rausholen die nicht den passenden Deserializer des 100.000sten Serialize-Format installiert haben.
    
    Serializer sind gut für die Kommunikation Maschine-Maschine. Sobald ein Mensch etwas damit anfangen soll geht das nicht mehr.
    OTRS-Erweiterungen (http://feature-addons.de/)
    Frankfurt Perlmongers (http://frankfurt.pm/)
    --
    
    Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
    Perl-Entwicklung: http://perl-services.de/
  - +13 replies
  - topeg
    
    2014-03-14 10:11
    
    User since
    2006-07-10
    2611 Artikel
    BenutzerIn
    
    1. CSV sind sehr einfach zu erzeugen.
    2. Viele Editoren und alle Tabellenkalkulationsprogramme können CSV öffnen und formatiert darstellen.
    3. Es werden im Extremfall keine weiteren Programme/Module gebraucht, um CSV zu untersuchen.
    4. CSV kommen als textuelles Format einem SQL-Dump recht nahe.
    5. Ich habe schon einen Parser geschrieben, warum sollte ich noch einen Serialisierer schreiben?
    6. Der ganze Code hat weniger als 300 Zeilen. Warum das mit einem speziellen Seriellisierer vergrößern?
    
    Und was ich hier postete ist auch nicht das was ich persönlich benutzt habe. Das ist eine "verallgemeinerte" Version. Mein Script hat die interessanten Zeilen gleich transformiert und hat sie im eigentlichen Zielformat wieder gespeichert (in meinem Fall wieder SQL). Hätte ich das gepostet, so wäre das für niemanden interessant gewesen. Einen SQL -> CVS Exporter ist dagegen nützlich, da man immer wieder SQL-Dumps hat, die weiterverarbeitet/untersucht werden sollen.
    
    Der eigentliche Parser ist als Modul gekapselt und lässt sich leicht aus dem Script heraus nehmen. Nimm es und erzeuge dein eigenes Exportformat.
    - +12 replies
    - rosti
      
      2014-03-14 12:55
      
      User since
      2011-03-19
      3472 Artikel
      BenutzerIn
      
      Hi,
      
      Dateien sind mit Perl generell einfach zu erzeugen. Letztendlich gehts darum, Datenstrukturen auf Byte-Ebene abzubilden ohne Informationsverlust. In DB-Feldern können sowohl NULL-Werte als auch Leerstrings vorkommen, dass muss nach einem Transport der Daten reproduzierbar sein, wie machst Du das in einer CSV? Dann hätten wir noch, bei einer textlichen Strukturierung, die Frage nach dem Feld-Trennzeichen zu klären, im einfachsten Fall wird dieses Zeichen in Nutzdatenfeldern maskiert.
      
      Aus Letzerem ergibt sich im Falle einer menschenlesbaren Darstellung wiederum eine Anforderung an den Editor, wobei die Entscheidung ob eines human readable format höchstens im zweistelligen Megabytebereich getroffen wird und bei Datenmengen, die an Gigabytes heranreichen völlig indiskutabel ist.
      
      Praktisch ist das die erste Entscheidung:
      Sollen Daten dargestellt oder transportiert werden?
      
      Du schreibst doch selbst, dass eine menschliche Lesbarkeit keine Rolle spielt, warum führst Du das jetzt als Argument für CSV?
      
      Dann wäre noch was: Textlich strukturierte Daten erfordern einen Parser und der kann erst dann arbeiten, wenn die Daten komplett im Hauptspeicher liegen. Es sei denn, die CSV kann zeilenweise abgearbeitet werden, woraus sich die nächste Frage ergibt, nämlich die, wie in Nutzdaten vorhandene Zeilenumbrüche nach CSV transformiert werden sollen. Freilich kann ein Datensatz in einer CSV auch auf mehrere Zeilen abgebildet sein, aber wozu überhaupt einen Zeilenumbruch als Trennzeichen für Datensätze?
      
      Nächste Frage: Datentypen in einer CSV-Datei.... Alles in Allem ist ein Transport über CSV o.a. mit textlich strukturierten Mitteln erzeugten Dateien alles Andere als einfach. Sequenzen erfordern auch keinen Parser, das Lesen einer Sequenz beginnt ummittelbar mit den ersten Bytes, das ist CPU und RAM-gefällig.
      
      Argumente wie Kompatibilität und Portierbarkeit sind ebenfalls nicht an CSV gebunden, das lässt sich auch mit proprietären Sequenzen lösen. Portierbarkeit: Unterschiedliche Plattformen reden Bytes. HTTP: Übertragen werden Bytes. FTP, Sockets... Bytesemantics. Nicht umsonst gibt es Schichtenmodelle.
      
      Schönes Wochenende!
      - topeg
        
        2014-03-14 19:39
        
        User since
        2006-07-10
        2611 Artikel
        BenutzerIn
        
        Ich schrieb
        Quote
        Sie sind nicht zwangsläufig menschenlesbar formatiert
        
        Was heißt, das der Konverter nicht darauf achtet was für Daten konvertiert werden. Wenn man Binärblobs aus dem SQL-Dump holt bekommt man ein CVS mit Binärdaten. Oder wenn die Datensätze Zeilenumbrüche enthalten. Dann werden sie in das CSV übernommen. Das mindert die Menschenlesbarkeit. Tabellenkalkulationen kommen damit aber klar, und auch Text::CSV.
        
        Wenn man aber einfache Werte Heraus holt bekommt man auch Menschenlesbares CSV.
        
        Und ich schrieb genauso, das Keinerlei weitergehende Validirung und Bewertung der Datensätze und Kommandos gemacht werden. So werden "NULL" Statements und andere Spezifische Angaben übernommen wie sie im SQL-Dump stehen.
        Und es war auch nicht mein Ziel einen vollständigen Parser zu schreiben. Sondern nur für mich wichtige Daten aus dem SQL-Dump zu lesen. Ich dachte das könnte auch für andere Interessant sein.
        Warum du jetzt von mir verlangst, das ich das in ein Binärformat wandeln soll erschließt sich mir nicht. Ich habe die Daten die ich brauche und dachte nur das ein solcher Parser auch für andere Interessant sein könnte.
        
        Und wie ich schon schrieb. Wenn du eine andere Ausgabe haben willst, steht es dir frei den Code zu nehmen und nach deinen wünschen zu modifizieren.
      - +10 replies
      - topeg
        
        2014-03-14 20:14
        
        User since
        2006-07-10
        2611 Artikel
        BenutzerIn
        
        2014-03-14T11:55:56 rosti
        Dateien sind mit Perl generell einfach zu erzeugen. Letztendlich gehts darum, Datenstrukturen auf Byte-Ebene abzubilden ohne Informationsverlust. In DB-Feldern können sowohl NULL-Werte als auch Leerstrings vorkommen, dass muss nach einem Transport der Daten reproduzierbar sein, wie machst Du das in einer CSV?
        
        Der Parser von mir Nimmt was im SQL-Stament steht, wenn da ein leerer sing ist, wir ein leerer Sing in das CVS geschrieben, Wenn dort "NULL" steht steht auch im CSV "NULL"
        
        2014-03-14T11:55:56 rosti
        Dann hätten wir noch, bei einer textlichen Strukturierung, die Frage nach dem Feld-Trennzeichen zu klären, im einfachsten Fall wird dieses Zeichen in Nutzdatenfeldern maskiert.
        
        Der Feldtrenner ist "," wenn im Datensatz selber "," vorkommt wird er mit '"' Gequotet und das Komma damit entwertet. Kommt ein '"' vor wird der Datensatz gequotet und das '"' durch duplizieren ('""') entwertet. Das folgt der CSV-Spezifikation ähnliches wird mit Zeilenumbrüchen gemacht.
        
        2014-03-14T11:55:56 rosti
        Aus Letzerem ergibt sich im Falle einer menschenlesbaren Darstellung wiederum eine Anforderung an den Editor, wobei die Entscheidung ob eines human readable format höchstens im zweistelligen Megabytebereich getroffen wird und bei Datenmengen, die an Gigabytes heranreichen völlig indiskutabel ist.
        
        Es ist aber Potentiell besser lesbar als ein Binärformat, das man nur wider mit einem speziellen Parser lesen kann. Die Frage ist einfach, was will man später mit den Daten machen. Wenn man sie direkt weiterverarbeiten will dann sollten man das Modul aus dem Script nehmen und die Weiterverarbeitung direkt nach dem Parsen machen. Wenn man aber einfach nur erst mal die Daten haben will um sie in einer Tabellenkalkulation ansehen zu können ist CSV kein so schlechtes Format.
        
        2014-03-14T11:55:56 rosti
        Praktisch ist das die erste Entscheidung:
        Sollen Daten dargestellt oder transportiert werden?
        
        Was redest du Ständig von Transport? Was genau willst du von mir? Ich kann Das ganze auch wider zurück nehmen. Ich dachte nur das es anderen ein Hilfe sein könne. Wenn du meinst das mein Code völliger Müll ist, dann lösche ich es halt.
        
        2014-03-14T11:55:56 rosti
        Dann wäre noch was: Textlich strukturierte Daten erfordern einen Parser und der kann erst dann arbeiten, wenn die Daten komplett im Hauptspeicher liegen. Es sei denn, die CSV kann zeilenweise abgearbeitet werden, woraus sich die nächste Frage ergibt, nämlich die, wie in Nutzdaten vorhandene Zeilenumbrüche nach CSV transformiert werden sollen. Freilich kann ein Datensatz in einer CSV auch auf mehrere Zeilen abgebildet sein, aber wozu überhaupt einen Zeilenumbruch als Trennzeichen für Datensätze?
        
        Du schreibst Unsinn. Schau dir meinen SQL-Parser an, ich habe nur "\n" als Ende einer Zeile gewählt weil die meisten SQL-Dumps in der Beziehung eine Beschränkung der Zeilenlängen haben. Genauso gut könne ich eine eine feste Anzahl von Bytes lesen und die verarbeiten, die Anpassungen wären minimal. Ein Parser muss nicht alles lesen um die Elemente Parsen zu können, er muss nur immer wissen im welchen "Status" sich der gelesenen String sich befindet. Ob er sich innerhalb eines Befehls eines Datensatz, eines Kommentars etc. befindet.
        
        2014-03-14T11:55:56 rosti
        Nächste Frage: Datentypen in einer CSV-Datei.... Alles in Allem ist ein Transport über CSV o.a. mit textlich strukturierten Mitteln erzeugten Dateien alles Andere als einfach. Sequenzen erfordern auch keinen Parser, das Lesen einer Sequenz beginnt ummittelbar mit den ersten Bytes, das ist CPU und RAM-gefällig.
        
        Und das kannst du auch einfach an Eine Tabellenkalkulation geben, um zu schauen was du da eigentlich hast. Ja bitte du hast recht, das CSV nicht das nonplusultra der Datenspricherung ist. Darum ging es mir auch gar nicht. Ich hatte einen SQL-Parser geschrieben und dachte mir. "Hey wäre sicher doch nützlich wenn man damit SQL-Dump-Tabellen als CSV speichern könne, das sind für mich 30 zusätzliche Zeilen zum Parser. Und man kann auch gleich sehen, wie man den Parser benutzen kann."
        
        2014-03-14T11:55:56 rosti
        Argumente wie Kompatibilität und Portierbarkeit sind ebenfalls nicht an CSV gebunden, das lässt sich auch mit proprietären Sequenzen lösen. Portierbarkeit: Unterschiedliche Plattformen reden Bytes. HTTP: Übertragen werden Bytes. FTP, Sockets... Bytesemantics. Nicht umsonst gibt es Schichtenmodelle.
        
        Wer sagt das die Daten irgendwohin transferiert werden sollen? Ich habe nie geschrieben, das sie irgendwohin transferiert werden sollen. Ich habe nur einen einfachen SQL-Parser geschrieben und darum ein kleines Script was CSV erzeugt. Mir ist es völlig egal wohin welche Daten auch immer transferiert werden. CVS ist einfach zu erzeugen und kann von vielen Programmen sinnvoll gelesen werden.
        
        Man nimmt den SQL-Dump den man lokal hat. Sagt dem Script in welches Verzeichnis die CSV Dateien geschrieben werden sollen und das Script rödelt den Dump durch. Wenn du mehr willst Passe das Script an. Ich verstehe nun wirklich deine Aggression nicht.
        
        2014-03-14T11:55:56 rosti
        Schönes Wochenende!
        
        Dir Auch!
        
        +6 replies
        
        rosti
        
        2014-03-14 23:53
        
        User since
        2011-03-19
        3472 Artikel
        BenutzerIn
        
        Lieber Topeg, ich habe hier nicht vor, Deine Arbeit herabzuwürdigen. CSV-Dateien sind mir im Berufsleben oft begegnet: Mit all den Nachteilen, die programmiertechnisch damit verbunden sind, vom CPU-lastigen Maskieren der Feld- und Recordtrenner über speicherlastige Parser, was mit anderen Dateiformaten weit weniger problematisch ist. Es mag momentan zutreffen, dass CSV und andere textlich stukturierte Formate portabel zu 3rd Software sind, aber das ist kein wirklicher Grund, sich für das CSV-Format zu entscheiden, am Wenigsten aus unserer Sicht als Programmierer.
        
        Agressivität hingegen ist das was MIR begegnet, immer dann, wenn ich meine diesbezüglichen Entwicklungen HIER versuche vorzustellen und da lasse ich mich genausowenig beirren wie Du. Serializer entwickle ich schon seit Jahren, mögen mich andere darüber belächeln, es ist nunmal mein Hobby, zielgerichtet auf zweckmäßige Dateiformate, die plattform- und anwendungsübergreifend nutzbringender sind als CSV, XML und JSON. Beispielsweise zur Übertragung vom multipart Content (text, video, adio, graphic, pdf...) zusammen in einer serverseitig erzeugten Binärsequenz, als Datenstruktur, die mit Javascript im Browser gleichermaßen wiederhergestellt wird.
        
        Das sind so Dinge, die ich vor Jahren in meiner Freizeit entwickelt habe, zu einer Zeit, wo Browser das noch gar nicht konnten, was sich mittlerweile aber auch geändert hat. In der Entwicklung gibt es keinen Stillstand und von dem, was sich derzeit im MDN tut, bin ich begeistert, obwohl das schon lange fällig ist und ich es andererseits bedauerlich finde, dass ich meine diesbezügliche Begeisterung hier mit niemanden teilen kann.
        
        Dir persönlich wünsche ich viel Erfolg und dankbare Feedbacks für Deine Publikationen.
        
        Rolf
        
        +3 replies
        
        topeg
        
        2014-03-15 01:52
        
        User since
        2006-07-10
        2611 Artikel
        BenutzerIn
        
        Ich kann dir aber immer noch nicht folgen. Außer einen Allgemein Ablehnung gegenüber CSV sehe ich keinen Vorteil ein anderes Format zu wählen. Der Code würde Komplexer und größer. Ich müsste noch beschreiben wie man Informationen aus meinem selbst gestrickten Datenformat extrahiert. Die Verwendung das Scripts würde schwieriger.
        Zudem bezweifle ich das dies der Wiederverwendbarkeit helfen würde.
        Bedenke das dieses Script unter Umständen Personen benutzen, die nur rudimentäre oder gar keine Programmierkenntnisse haben. Da ist es am besten ein Bekanntes und weit verbreitetes Format zu nutzen, selbst wenn es nicht ideal ist.
        Deine Aussagen mögen alle korrekt sein, aber das mindert nicht die Verbreitung des Formats. Betrachte es aus der Sicht eines Anwenders. Besser ein schlechtes Format das man überall öffnen kann, als ein gutes, das keiner kennt. Ja sicher ist das lesen von CSV unter Umständen Langsam und Speicherhungrig. Aber man hat wenigstens die Möglichkeit.
        Sicher könnte ich es z.B. auch als BerkeleyDB speichern. Aber damit kann nur ein Programmierer etwas anfangen, und der kann den Code auch leicht umschreiben um die Ausgabe von CSV zu BerkeleyDB zu ändern wenn er es wünscht. Der Code ist dahingehend nicht sehr komplex.
        Hätte ich es _nur_ für Programmierer geschrieben, hätte ich hier das reine Modul präsentiert. Aber ich wollte auch etwas für mögliche Anwender geben.
        
        Mein primäres Augenmerk war der Parser nicht das eher nebensächliche Datenformat zur Ausgabe. Das war nur eine Nettigkeit, kein zentraler Faktor der Entwicklung. Ich konnte eine sinnvolle Ausgabe in 20 Zeilen schreiben, also habe ich es gemacht.
        
        Ich kann immer noch nicht verstehen, was daran nun der Kritikpunkt sein soll. Du beschwerst dich über 20 von 300 Zeilen. 20 Zeilen die mit Leichtigkeit geändert werden können, die kein essenzieller Teil des Parsers sind.
        Für mich ließ es sich als ob du dich bei einem Auto darüber ärgerst das der Anhänger die falsche Form hat.
        Sicher kannst du allgemeine Kritik an einem Datenformat üben. Aber das in direkte Beziehung mit meinem Script zu setzen halte ich nicht für angebracht.
        
        +2 replies
        
        pq
        
        2014-03-15 10:18
        
        User since
        2003-08-04
        12208 Artikel
        Admin1
        
        2014-03-15T00:52:32 topeg
        Besser ein schlechtes Format das man überall öffnen kann, als ein gutes, das keiner kennt.
        
        Bitte lass dir das nicht miesmachen. CSV ist kein schlechtes Format. Es gibt sinnvolle Einsatzzwecke, und welche, bei denen man was anderes nehmen sollte.
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        topeg
        
        2014-03-15 12:59
        
        User since
        2006-07-10
        2611 Artikel
        BenutzerIn
        
        Keine Sorge ich halte CSV für ein einfach zu erzeugendes aber nicht ganz einfach zu lesendes Tabellen-Format. Ich habe sonst keine besonderen Abneigungen. Ich kann die Abneigungen von rosti insofern nachvollziehen, als das das Format Untiefen enthält, die gerade Anfänger in der Parser-Programmierung leicht übersehen. Das resultiert dann in nur partiell funktionstüchtigen Parsern, die nur mit einem Subset von CSV klar kommen. Das war mir an der Stelle aber Egal, da ich nur ein brauchbares Ausgabeformat brauchte.
        
        GwenDragon
        
        2014-03-15 09:40
        
        User since
        2005-01-17
        14748 Artikel
        Admin1
        
        2014-03-14T22:53:03 rosti
        Agressivität hingegen ist das was MIR begegnet, immer dann, wenn ich meine diesbezüglichen Entwicklungen HIER versuche vorzustellen und da lasse ich mich genausowenig beirren wie Du.
        Deinen Hinweis auf die Aggressivität der Community hier verstehe ich nicht so ganz. Ok, jeder ist verschieden in der Empfindsamkeit.
        Wenn du von Agressivität redest, hast du noch nie erlebt was konkurrenzneidige und fanatische Leute mit ihrem Hass und Terror wirklich anrichten bei Programmierenden in der Community.
        
        Nachfragen bezüglich der Anwendbarkeit sind vielleicht störend für dich.
        Vergleiche mit anderen Formaten und Programmierideen sind unmöglich.
        Bislang hast du nicht dargestellt, wo dein Serialisierungsformat sinnvoller ist, wenn SQL-Dumps erzeugt und durchsucht werden sollen.
        
        Quote
        Serializer entwickle ich schon seit Jahren, mögen mich andere darüber belächeln, es ist nunmal mein Hobby, zielgerichtet auf zweckmäßige Dateiformate, die plattform- und anwendungsübergreifend nutzbringender sind als CSV, XML und JSON.
        Ich belächel nix, das wäre respektlos. Ich schau mir immer mal an weas andere machen und lerne daraus.
        Was wäre das Internet ohne neue Ideen und Anregungen.
        
        Wenn es dein Hobby ist musst du natürlich nicht irgendwo in Konkurrenz/Vergleich treten zu anderen Ideen, Datenstrukturen und Modulen.
        
        Quote
        Beispielsweise zur Übertragung vom multipart Content (text, video, adio, graphic, pdf...) zusammen in einer serverseitig erzeugten Binärsequenz, als Datenstruktur, die mit Javascript im Browser gleichermaßen wiederhergestellt wird.
        Neue Protokolle und Serializer sind interessant, asber ich seh nirgendwo Testcases und Code, nur kurze Schnippsel. Und dass es bei dir Closed Source ist macht es niemand einfach es zu beurteilen.
        Aber es ist verständlich, dass du deine Idee schützen willst.
        
        Viel Erfolg mit deiner Idee und deinen Programmen.
        :)
        die Drachin Gwen
        
        Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
        
        pq
        
        2014-03-15 10:56
        
        User since
        2003-08-04
        12208 Artikel
        Admin1
        
        2014-03-14T22:53:03 rosti
        Agressivität hingegen ist das was MIR begegnet, immer dann, wenn ich meine diesbezüglichen Entwicklungen HIER versuche vorzustellen und da lasse ich mich genausowenig beirren wie Du.
        
        Das ist ja mal putzig, dass Kritik gleich als aggressiv bezeichnest.
        
        Ich würd mal sagen, die Perl Community allgemein wie auch diese hier ist generell nützlichen Sachen sehr aufgeschlossen. Manche sind kritischer, manche laufen jedem Hype hinterher, das ist normal.
        
        Eine ernstgemeinte Frage: Warum glaubst du, werden deine Entwicklungen kritisiert? Weil man dich nicht leiden kann? Kennt dich hier jemand persönlich, mit dem du schonmal Streit hattest? Glaubst du, es liegt an deinem Avatar? Was fur einen Grund sollte es geben?
        Glaub mir, es gibt Leute in der Community, die sich richtig unsympatisch verhalten, aber die durchaus geniale Sachen programmieren. Wenn etwas gut ist und man auf fachlicher Ebene mit den Leuten reden kann, wird es angenommen.
        
        Vielleicht gibt es einfach von deiner Seite aus noch Verbesserungsbedarf, wie du deine Ideen präsentierst und wie du auf konstruktive Kritik und Fragen eingehst. Aus meiner Erfahrung blieben viele Fragen an dich offen. Aus meiner Sicht bist du einigen Fragen und Kritikpunkten aus dem Weg gegangen. Dann zu behaupten, dass die Leute "HIER" dir gegenüber aggressiv sind, halte ich für ziemlich unfair und pauschal.
        
        Schau dir an, was alles so in der Perl Community vorgestellt wird und wie es angenommen wird. Das passiert naturgemäss meist nicht hier, sondern eher auf Plattformen wie blogs.perl.org, da man damit die internationale Community erreicht. Und schwupps ist ein Projekt auf github, und jeder kann es sich auschecken.
        Mit einem Projekt wolltest du sogar Geld verdienen. Keiner konnte den Code sehen, und Fragen blieben wie oben schon erwähnt, teilweise unbeantwortet. Was erwartest du denn, wenn du sowas in einem Forum vorstellst?
        
        Behalte dir deine Begeisterung, aber denk dran, dass manches, was für dich neu und genial erscheint, für andere ein alter Hut, schlechter Stil oder sonstwas sein kann.
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        Linuxer
        
        2014-03-15 00:43
        
        User since
        2006-01-27
        3890 Artikel
        HausmeisterIn
        
        2014-03-14T19:14:48 topeg
        Ich kann Das ganze auch wider zurück nehmen. Ich dachte nur das es anderen ein Hilfe sein könne. Wenn du meinst das mein Code völliger Müll ist, dann lösche ich es halt.
        
        Ich bitte Dich, es stehen zu lassen.
        Ich gebe zu, ich habe es mir noch nicht angesehen und ich habe derzeit auch keinen Verwendungsfall dafür, aber vielleicht brauchen ich oder andere sowas mal in Zukunft.
        
        Lass Dir bitte von rosti nicht den Tag oder die Nacht versauen.
        Last edited: 2014-03-15 00:59:20 +0100 (CET)
        meine Beiträge: I.d.R. alle Angaben ohne Gewähr und auf Linux abgestimmt!
        Die Sprache heisst Perl, nicht PERL. - Bitte Crossposts als solche kenntlich machen!
        
        +2 replies
        
        pq
        
        2014-03-15 11:20
        
        User since
        2003-08-04
        12208 Artikel
        Admin1
        
        2014-03-14T19:14:48 topeg
        Ich verstehe nun wirklich deine Aggression nicht.
        
        Das als Aggression zu bezeichnen, halte ich aber auch für übertrieben.
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        topeg
        
        2014-03-15 13:03
        
        User since
        2006-07-10
        2611 Artikel
        BenutzerIn
        
        Was mir ein wenig sauer ausgestoßen ist, das rosti nur die CSV-Ausgabe kritisierte, ohne eine alternative zu präsentieren, welche eine nach seiner Sicht besser wäre.
        Kein Wort darüber was ihm am Parser stört oder ob er das ganze überhaupt für sinnvoll hält.
        Das habe ich als aggressive Verhalten verstanden. Ich habe nichts dagegen kritisiert zu werden. Aber Kritik sollte konstruktiv sein. Und wenn es allgemeine Kritik ist, dann sollte sie auch so formuliert sein und nicht in direkter Beziehung auf meinen Code. etwas in der Art.
        "Ich finde CSV nicht gut weil [...] ein Serializer wie <xyz> wäre sicherlich eine bessere Lösung ..."
        und nicht
        "Warum machst Du das so umständlich über eine CSV-Datei [...] Ich programmiere schon seit Jahren Serializer, ..."
        Das kommt bei mir so an wie "Bist du bescheuert [...] ich bin so viel besser"
        Eine CSV-Datei ist nicht umständlich zu erzeugen. Und es ist toll das er schon seit Jahren Serializer schreibt, aber wie soll das meinen Code verbessern? Was soll die Anmerkung? Soll sie ihm Glaubwürdigkeit geben? Hier im Kontext ohne Nachweis wirkt es fehl am Platz.
  - GwenDragon
    
    2014-03-14 10:27
    
    User since
    2005-01-17
    14748 Artikel
    Admin1
    
    @rosti
    Du hast vielleicht deinen Serializer immer dabei, vielleicht auf CD oder Stick.
    Über Datendump mit deinem Serializer HTTP versenden? Unverschlüsselt? nee, oder?
    
    Ich sehe in dem Uralt-Dateivormat CSV da Vorteile.
    Die gedumpten CSV-Dateien kann man eben einfacher mit Textverarbeitung oder einfachem Editor öffnen, komprimieren, sogar über ssh woanders hin tunneln.
    die Drachin Gwen
    
    Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
- +2 replies
- pq
  
  2014-03-15 11:29
  
  User since
  2003-08-04
  12208 Artikel
  Admin1
  
  Hattest du dir auch mal SQL::Translator angesehen? Da man damit diffs von SQL-Statements machen kann, könnte ich mir vorstellen, dass man damit auch deinen Dump parsen kann. (Habe aber bisher nur Schemata damit verglichen, also CREATE-Statements etc.)
  Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
  lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
  - topeg
    
    2014-03-15 13:01
    
    User since
    2006-07-10
    2611 Artikel
    BenutzerIn
    
    Ja ich hatte kurz hinein geschaut. Zum einen schien mir das nicht direkt das was ich brauchte, zum anderen war es mir zu undurchsichtig.
    Es war eine Sache der Abwägung. Entweder ich schreibe einen Parser, oder ich Versuch mich daran das Modul für meine Zwecke zu nutzen / zu erweitern.
    Den Parser habe ich in 6 Stunden geschrieben und getestet. Ich bin mir nicht sicher, ob ich das genauso schnell und überhaupt mit SQL::Translator hin bekommen hätte.
    Aber ja SQL::Translator könnte eine besser Lösung sein, da der Parser dort auf jeden Fall vollständiger ist.
    
    Ich hatte mir auch SQL::Parser angeschaut. Aber das schien es mir das der Parser zu viel zwischenspeichert, was zu Speicher-Problemen hätte führen können. Zudem wirkt der Parser auf mich nicht sehr Robust. Wie ich schon sagte hatte ich die Befürchtung, das der SQL-Dump beschädigt war. Das sind rein Subjektive Eindrücke gewesen.
    
    Zudem wollte ich auch mal schauen wie sich SQL Parsen lässt. :-)

View all threads created 2014-03-14 02:28.