psql rosetta

Btrieve / Pervasive.SQL / ZEN: Rosetta-Code-Beispiel-Repository-Projekt

Idee

Stellen Sie dokumentierten Beispielcode für alle von Pervasive.SQL unterstützten Datenbankzugriffsmethoden auf allen Plattformen und in allen gängigen Sprachen bereit. Vorzugsweise als Nachschlagewerk für Anfänger und Fortgeschrittene geeignet.

Name

Sehen:

• Rosetta-Stein
• Rosetta-Code

Hintergrund

Viele Jahre lang fiel mir auf, dass Code/Codierungsbeispiele rar waren. Sie variierten auch im Laufe der Zeit (Plattformen, unterstützte Sprachen), blieben aber vor allem in der Zeit hängen. Für den Anfang nicht sehr ansprechend, egal ob er neu in einer Programmiersprache oder in Pervasive.SQL ist. Im Laufe der Jahre entwickelte ich Ideen, wie ich dies verbessern könnte, und unternahm einige Anstrengungen, Code zu schreiben. Die vor uns liegende Aufgabe ist recht umfangreich. Vor allem, wenn man einen ordentlichen Job machen will. Ideen ändern sich, neue Projekte oder Aufgaben geraten dazwischen usw. Kurz gesagt, es hat einige Zeit gedauert und das Ergebnis ist ganz anders als zunächst erwartet, da meine erste Idee darin bestand, eine einzige Referenzanwendung zu schreiben, die später in andere Sprachen portiert werden könnte. Plattformen.

Layout

Basierend auf dem Abschnitt „Datenbankzugriffsmethoden“ in der Online-Dokumentation zu Actian Pervasive.SQL V13 habe ich ein Bash-Shellskript (mk_dirs.sh) erstellt, das als einzelnes Argument den Namen der Programmiersprache verwendet und eine Verzeichnisstruktur erstellt, die alle Datenbankzugriffsmethoden als Unterverzeichnisse auflistet. Durch die Verwendung dieses Skripts war ich gezwungen, alle (?!) Möglichkeiten zu untersuchen und zu dokumentieren, egal wie seltsam sie auch sein mögen. Alle Unterverzeichnisse enthalten ihre eigene Markdown-ReadMe-Datei, in der die (Un-)Möglichkeiten und Code beschrieben werden, falls bereitgestellt. Alle Programmiersprachen verfügen über eine ReadMe-Markdown-Datei in ihrem Stammverzeichnis, die die Vor- und Nachteile beschreibt, was implementiert ist und was nicht, sowie eine Ergebnis-Markdown-Datei, um zu registrieren, was auf welcher Plattform getestet wurde.

Fehlende Dateien versus Urheberrecht

Das Ziel bestand darin, keine Urheberrechte zu verletzen, daher müssen Header von SDKs kopiert werden, die von der Actian-Website heruntergeladen werden können. Das Gleiche gilt für Beispielcode, der von der Website kopiert/eingefügt werden kann. Es wäre großartig, wenn Beispielcode (und Header) aus einem Repository verfügbar gemacht werden könnten. Wenn man sich auf Github umsieht, kann man urheberrechtlich geschützte Header-Dateien finden. Ich überlasse es Actian, sie hinzuzufügen.

Verbesserungen

Ich freue mich sehr über Verbesserungen, Kommentare und andere Beiträge. Persönlich kann ich mir eine Ansicht vorstellen:

• Der gesamte Code sollte den Codierungsstandards entsprechen.
• Refactoring/Bereinigung des Codes.
• Der gesamte Code sollte sehr viele Kommentare enthalten. Kommentieren Sie alle Datenbankaufrufe.
• Der gesamte Code sollte sehr defensiv gestaltet sein: Wenn ein Fehler auftritt, sollte er gemeldet oder zumindest protokolliert werden.
• Der gesamte Code sollte ordnungsgemäß getestet werden. Am besten auf allen relevanten Plattformen. Was wiederum dokumentiert werden sollte.
• Code muss für andere Plattformen geschrieben oder angepasst werden. Insbesondere: Mac, IOS, Android
• Einige offensichtliche Sprachen/Plattformen fehlen. Insbesondere: Win/VS: c#, VB.net, Win/Embarcadero C++, Win/MingW oder anderes GNU C/C++, IOS/Objective C, Android/Java, Mac/Kompatibilität/Unterstützung der Bash-Shell-Skripte.
• Außerdem gibt es für einige Sprachen, die früher unterstützt wurden/wichtig waren, noch keinen Beispielcode. Was fällt mir ein: Cobol, Delphi, ...? Und einige sind nicht mehr wichtig: (Visual) Basic (vor .net), Pascal, Turboc (DOS), Watcom C/C++ (DOS)
• Einige „Sprachen“ sind nicht sehr nachweisbar, da sie offenbar umfangreiches Boilerplating, Projektmanagement und/oder Integration in eine IDE erfordern. ASP.NET ist ein Beispiel.
• Integrierte Plattformen werden nicht aufgeführt. Zum Beispiel macht es wahrscheinlich keinen Sinn, sie aufzulisten. Andere in der Vergangenheit verwendete Plattformen: Clarion und Power Builder
• Ein weiteres Thema, das Aufmerksamkeit erfordert, ist die webbasierte Entwicklung. Man kann sich vorstellen: Windows/ASP, Python/Flask, Python/Django, Ruby/Ruby-on-Rails und Javascript, NodeJS. Optional erweitert durch neue Kids im Block wie Dart/Flutter, Meteor usw., obwohl viele davon auf Javascript basieren.
• Treiber. Im Moment fällt mir besonders eines ein: SQLAlchemy-Pervasive: Es bedarf einer ernsthaften Pflege.
• Derzeit liegt ein starker Fokus auf der Datenbankanbindung. Letztendlich wäre eine Anwendung, die Befehlszeile, Flüche (TUI) und GUI unterstützt und gleichzeitig alle in APIs (Btrieve, Btrieve2, ODBC, JDBC) verfügbaren Aufrufe nutzt, ein echter Bonus. Es würde sich als Demo eignen, veranschaulichen, wie Aufrufe verwendet werden sollten, und wäre natürlich ein großartiger Test, insbesondere wenn der Code mithilfe der Testautomatisierung ausgeführt werden könnte. Es wäre wichtig, dies ordnungsgemäß zu entwerfen und umzusetzen. Allein ein paar kleine Schritte in diesem Prozess wären großartig.

Mir ist völlig bewusst, dass der meiste Code nicht den oben genannten Standards entspricht. Das Refactoring des gesamten Codes würde viel Zeit in Anspruch nehmen, was die Erstveröffentlichung verzögern oder vielleicht sogar verhindern würde. Aus diesem Grund veröffentliche ich Code, der nicht meinen Vorstellungen von ordnungsgemäßem Codieren entspricht.

Credits

Siehe die Datei Credits.md. Diese Datei gilt für das gesamte Projekt.

Lizenz

Siehe die Datei License.md. Diese Datei gilt für das gesamte Projekt.

Warnungen

Der Vollständigkeit und Einheitlichkeit halber sind alle im Programmierhandbuch erwähnten Zugriffsmethoden als Optionen für alle Sprachen aufgeführt. Die Kombinationen können durchaus absurd oder exotisch sein. Offensichtlich sind insbesondere diese (noch) nicht implementiert und/oder nicht ordnungsgemäß getestet. Der gesamte Code und die gesamte Dokumentation in diesem Repository werden unverändert bereitgestellt. Ich bin keineswegs ein Experte für alle angebotenen Sprachen. Das Ziel besteht darin, zumindest funktionierenden Code zu liefern, der einem sehr niedrigen Standard entspricht, aber leider keine Seltenheit ist. Das Schreiben über Programmierung versus Software-Engineering kann Bücherregale füllen. Lass uns jetzt nicht dorthin gehen. Hoffentlich wird die Qualität des Codes mit der Zeit steigen, wenn Leute mit Experten in einer bestimmten Sprache teilnehmen und den Code verbessern. Sofern nicht anders angegeben, wird der meiste Code nur unter Linux getestet. Um die Reife und Klarheit dieses Themas zu verbessern, wurden Testergebnistabellen hinzugefügt.