Änderung Create/Delete Database Statement (storemysql.py)

[Marmos76]

Änderung der Databank-Erzeugung

1. Item nur wenn diese noch nicht existiert
2. Item Fehlerfall
   • lösche nicht die Datenbank, sondern
   • lösche nur die einzelnen Tabellen und Prozeduren

Ich weiß leider nicht wer hochladen darf und wer nicht. Als ich den Push machen wollte, durfte ich nicht. Daher die geändert storemysql.py anbei. ZielOrdner plugin.video.mediathekview/resources/lib

Vllt. könnte ja einer der Berechtigten ein diff durchführen und die Änderung entspr. einpflegen. Viel Spaß Martin

storemysql.py.tar.gz

[codingPF]

Schau doch mal hier...gibt aber auch einige Tutorials... https://opensource.com/article/19/7/create-pull-request-github

Summary

• Find a project you want to contribute to
• Fork it
• Clone it to your local system
• Make a new branch
• Make your changes
• Push it back to your repo
• Click the Compare & pull request button
• Click Create pull request to open a new pull request

PS. Ich habe meine Änderungen jetzt auch gepusht...rebase nicht vergessen :-)

[Marmos76]

Dankeschön Git kenne ich aber gut und weiß nun dass ich definitv keine Rechte für ein push habe !! Git ist nicht mein Problem. Ich werde nach User und Passwort gefragt und dann Ätsch, Du darfst nicht.

Und wenn jeder Entwickler einen neuen Branch aufmachen muss, warum gibt es nur 3 insgesamt ? Git -Repo: -master -develop -feature

Die Anleitung hiflt dabei leider kein bisschen.

UPS Sorry !! Ich muss mich etwas korrigieren, denn ... Das Fork Modell ist mir etwas zu modern. Kenne ich in der Form noch nicht. Scheint ja auch etwas Github eigenes zu sein, denn "git fork" gibt es nicht. Dieses Entwuf-Konzept ist neu für mich. Hier liegt also der Hund begraben. ;-)

[alex1702]

UPS Sorry !! Ich muss mich etwas korrigieren, denn ... Das Fork Modell ist mir etwas zu modern. Kenne ich in der Form noch nicht. Scheint ja auch etwas Github eigenes zu sein, denn "git fork" gibt es nicht. Dieses Entwuf-Konzept ist neu für mich. Hier liegt also der Hund begraben. ;-)

Das ist nicht nur bei Github so, auch bei Gitlab und allen anderen Webbasierten Gitlösungen. Mit diesem Modell muss ich nicht jedem schreibrechte auf das Repo geben. Man forkt sich einfach das Projekt. Arbeitet in einem der Branches oder macht einen extra Branch. pusht das in seinen lokalen Fork und kann dann einen Pull Request gegenüber den Orginalprojekt machen.

[codingPF]

Ich habe mir das "drop ..." im Exception Block einmal angesehen und frage mich ob man das überhaupt will. Wenn ich so an das debuggen denke, dann will ich doch sehen wo das Ding abgeraucht ist...also hat das create table nicht geklappt (weil Rechte fehlen) oder das create procedure oder weil das dritte script fehlerhaft war etc....

[Marmos76]

Stimmt auch wieder. Dennoch möchte man ja keine großen Müllhaldenn erstellen. Also eigentlich müsste man es weglassen aber unter Configuration es wählen können. Zudem sind alle Tabellen hard gecodet. Das ist noch etwas Potential ... ,-)

Dennoch ich habe jetzt einen eigenen Fork und wollte dann dann den rebase machen. Aber in Github verstehe ich das ganz Modell nicht. Wie kann man denn wirklich das ganze nutzen ?' Also vom Schema

1. Fork in Github
2. git clone
3. Änderungen einpflegen, pushen / pullen
4. git remote add upstream https://github.com/mediathekview/plugin.video.mediathekview.git
5. git rebase master

hmm und dann habe ich dafür keine Rechte. So verstehe ich zumindest die Anleitung. In einem Blog habe ich gesehen : git rebase upstream/master

Kann das richtig sein ? beides ? https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/syncing-a-fork

[alex1702]

Punkt 4 und 5 sind vollkommen falsch und brauchst du nicht. Wenn deine änderungen gepushed sind, dann machst du auf der webseite ein pull request auf. (Ich weiß grad nicht ob du es auf unserer oder auf deiner seite initialisieren musst. Vermutlich auf unserer unter pull requests) Wählst dein branch und den bei uns ( in deinem fall master und master). Und dann nur noch abschicken.

[alex1702]

Ich meine die tabellen zu löschen anstatt die db kann vorteile haben bezüglich rechte des mysql benutzers. Aber mir gefallen mehrere dinge nicht.

1. finde ich es nicht so geil eine liste der tabellen dort aufzuführen, diese muss dann immer mitgepflegt werden.
2. wieso sind die befehle in einem dict. Ich weiß nicht was das für ressourcen unterschiede bei python macht, wenn man ein dict mit string keys nutzt anstatt zwei einzelne strings oder aber halt den befehl direkt da hin zu schreiben. Aber zumindest ich komme aus einer welt, in der ich versuche ressourcen zu sparen.

Auch wüsste ich von dir gerne noch mal, warum es besser wäre nur die Tabellen und nicht gleich die ganze Datenbank zu löschen? Hattest du das Problem irgendwo anders angesprochen?

[Marmos76]

Echt vielen Dank für Deine Unterstützung und Anregungen.

DB Löschen: Na, da hätte ich die Probleme, dass ich diese wieder komplett neu erstellen müsste und zwar so wie es das plugin nicht hergibt. Dann müsste man es evlt. eben so machen. Gut. Zumindest radikal und sauber !

Hash / Dict / String: Das macht hier nun echt keinen wirklichen Unterschied. Das Dictionary wird hier erzeugt und als bald wieder zerstört ... sehr lokaler Scope. Ich finde es aber gut, dass man weiß was man hat und möglichst zusammen hat. Das mit der doppelten Pflege stimmt aber gerade schon. Besser wäre zum Beispiel ein Array oder Dictonary von Dictiontaries in denen man die Tabellen und Proceduren extra auflistet und pflegt, wie ....

SQL['dbtabllen'] = TABELLEN{
'status' : "Create table ...",
'film' : "Create table ...", ... } SQL['dbproceduren'] = PROCEDUREN { 'ftInsertChannel' : "Create Procedure ...",
'ftInsertFilm' : "Create Procedure ...", ... }

und die am besten noch ausgegliedert in eine extra Datei ( z.B. Modul), das via import eingebungen wird. z.B. SQLDefinitionen.py

import SQLDefinitionen

Auf diese Weise hätte man zumindest alles zusammen und müsste nicht an zwei Orten pflegen. Die Dictionaries kann man eben nach belieben durchiterieren und man würde dementspr. nichts vergessen.

[codingPF]

das Thema hat sich mit der neuen Version im DEV Branch dann auch erledigt

[codingPF]

Released to 1.0.0 master