Closed Mac2 closed 11 years ago
masel
commented
12 years ago Die iwdb.sql zu ändern bringt aber auch nur bei der Neuinstallation der DB was. Beim Updaten einer gefüllten DB gibts Probleme. An der Lösung des Problems häng ich auch grad mit dem (Auto)updater...
balouh
commented
12 years ago es kommt auf alle Fälle noch nen größeres Update der sql, da noch nicht alle Gebäudebeschreibungen drin sind, das fülle ich gerade auf.
Mac2
commented
12 years ago Gerade was die Gebäude, etc angeht ist es eh die Frage ob es so sinnvoll immer eine aktuelle Version aller Daten bereitzustellen... durch die entsprechenden Parser für die Infoseiten, kann man die ja auch recht unproblematisch nachtragen ... das würde die Pflege der SQL auf jedenfall vereinfachen.
@masel: genau das Problem meinte ich auch ... nachträgliche Updates der DB sind bisher ja wieder nur per phpmyadmin möglich... evtl vereinfacht eine Trennung von Struktur.sql und Content.sql das Problem schon ein wenig ?
masel
commented
12 years ago Ich denke schon, ja. Dann kann ich Änderungen an der Struktur besser verfolgen.
Tante Edit sagt das unbedingte aktuell halten hier muss auch nicht sein. Auch wenn sich ggf nur ein Gebäude ändert ist das dann jedes Mal ein aktualisieren der gesamten content.sql (bzw besser(?) entsprechender TabellenContent.sql ' s). Wenn sich wer kümmern will bitte, aber ansonsten kostet das nur unnütz Zeit, die wir nicht haben. Da kann man sich bei Gelegenheit auch was bequemeres einfallen lassen.
Mac2
commented
12 years ago stimmt, in unserer DB gibts z.b. auch so gut wie keine "statischen" daten mehr ...
balouh
commented
12 years ago naja, der Gebäudeparser funzt halt nicht, der bisherige iwdb-Parser kommt mit den beiden "kostet" nicht zurecht und trägt in den Baukosten dann die Unterhaltskosten ein. Momentan steht in der Gebäudetabelle außer der richtigen Geb-Namen und IW-IDs zeimlich viel Müll und das wollte ich noch aufräumen, ist aber echt mühselig.
Mac2
commented
12 years ago das ist kein Problem, Parser für alle Infoseiten sind im neuen Format vorhanden ...
Thella
commented
12 years ago trennung von struktur & grunddaten absolutes muss! sowohl für die versionierung als auch sonst. ich würde noch net mal den admin in die user-table schreiben, sondern bei ner leeren user-table speziell einloggen lassen. sprich, die grund-db hat tatsächlich 0 zeilen und läuft. das ursprüngliche konzept war ja, dass Module per PHP-Code ihre Struktur-Daten hinzufügen und bei De-Installation wegnehmen. ansich net schlecht die idee. da aber module mittlerweile abhängigkeiten untereinander aufgebaut haben, klappts so gar net. wenn man die permutation bedenkt, die an szenarien entsteht, das modul a ist installiert, b nicht, version 1 installiert, auf 3 soll upgedated werden, praktisch unkontrollierbar. um das in den griff zu bekommen folgender vorschlag:
[Pseudo-Code] // User-Table - Da steht der Pöbel if table does not exists create table end if [/Pseudo-Code]
[Pseudo-Code] // release 1.3.4 added field balon_aufblasen for module schuh if field does not exists add field to table end if [/Pseudo-Code]
So wird jedes SQL-Struktur-Skript zum einen mergebar, aber du kannst auch jederzeit Struktur-Updates (!) von jeder Version auf jede andere vornehmen.
Eine Daten-Migration ist fortlaufend schwieriger. Und würde ich persönlich mir auch net antun für 10 Installationen der iwdb.
Aber wenn ich müsste, würde jede iwdb.sql die ausgeführt wird aus jedem branch, seine major,minor,revision die man ja aus "Git-/SVN-Whatever" bestimmt bekommt, in die DB schreiben. natürlich bei jeder ausführung. in eine versions-tabelle.
Dann kann ein Developer der in Version 1 shice gebaut hat, diese in Version 2 korrigieren, aber vorher kucken, ob wir net schon bei Version 3 sind, bevor er auf die Scans-Tabelle jagt.
Die erwähnten DB-Schema-Diff-Tools gibt es wirklich. Wenn du willst zeig ich sie dir gerne. Aber für die erwähnte Methodik sind sie einerseits unnütz und auch kontraproduktiv.
masel
commented
12 years ago Da hab ich auch schon ein Problem: balouh bei deiner letzten Änderung des DB Inhalts, haben sich teils die Gebäudeids geändert. Wäre jetzt Ansich nicht schlimm, nur das die Sitteraufträge hald auf die IDs und nicht auf die Gebnamen lauten. D.h. da standen nach dem Update ganz andere Gebäude in den Sitteraufträgen. Bei den anderen Aufträgen ist das wahrscheinlich ähnlich. Müssten wir uns was einfallen lassen wie wir das verhindern. Entweder ein (komplexer) Updatemechanismus bei dem auf jeden Fall die IDs erhalten bleiben oder die Sitteraufträge auf die jeweiligen Namen und so umschreiben oder noch was anderes? Vorschläge?
balouh
commented
12 years ago ich würde mir da nicht so die Gedanken machen. Es gitb ein paar Tabellen, die ansich nicht verändert werden. Dazu zählt in aller Regel der content von den Forschungstabellen, Gebäuden und Schiffen (da Hasi ja atm nichts mehr ändert) Einmal alle Gebs und Forschungen drin, wird alles Neue hinten angehängt. Wir haben leider zu Beginn der Runde nichts Aktuelles gehabt, in allen DBs, die ich in den Fingern hatte, waren veraltete/nicht mehr vorhandene Forschungen, Gebs und Schiffe drin.
Edith sagt..:: ich glaube, das hier ist ein Thema, dass sich im Forum besser diskutieren lässt
masel
commented
12 years ago Naja aber bis die Tabellen komplett sind gibts beim Updaten Chaos weil eine Ally das evl. in einer anderen Reihenfolge in die DB geparsed hat (und dann die Sitteraufträge nicht mehr passen) bzw eine möglicherweise eingestellte Geb-Kategorie Reihenfolge wird verstellt (weil das in der selben Tabelle ist) oder gar keine Updates und jede Ally darf das alleine parsen. Oder ein Updater muss das irgendwie passend zusammenbasteln, dauert dann hald. Sind ja wie gesagt nicht nur die Gebäude sondern auch (komplexe) Forschungsabhängigkeiten. Hmm
masel
commented
12 years ago Nochmal drüber nachgedacht: Ich glaub das einfachste ist die IDs gegen Hashes des ursprünglichen Namens zu tauschen. Das wäre dann überall eindeutig und ein Updater könnte durchgehen und schauen ist schon da? nein? hinzufügen... Wenn man jetzt die Möglichkeit beibehalten will die Namen so wie jetzt über das Adminmenü ändern zu können.
Mac2
commented
12 years ago ich seh nicht so wirklich den Vorteil, wenn wir von (eindeutigen) IDs auf eindeutige Hashs umstellen. Die IDs sind doch nicht wirklich für irgendwelche Reihenfolgen relevant, oder etwa doch ? Zudem hängt der Hash 1:1 vom Namen ab, bei Gebäuden mit Ausbaustufen (HGs, etc) wäre das dann jedesmal ein komplett neues Gebäude, anstatt einer Erweiterung (k.a. wie das im Moment überhaupt gehandhabt wird). Auf jedenfall würde man sich mit (ausschließlichen) Hashs eine zusätzliche Abhängigkeit auferlegen, die später noch zu einem Probleme werden könnte... vom Aufwand des Einbaus mal ganz abgesehen ;-)
Da übrigens durch die neuen Parser sowohl Forschungen als auch Gebäude und Schiffe hinzugefügt/aktualisiert werden können, ist ein komplett statischer Content der von uns vorgegeben wird eh auf Dauer problematisch. Ein gewisser Grundstock zum Starten macht natürlich Sinn, aber dann vlt nicht als fertige Tabelle, sondern als Reihe von Inserts (die dann eben die IDs automatisch passend zur bestehenden DB generieren würde). Also irgendwas a la "INSERT INTO ... ON DUPLICATE KEY ..."
Falls Bedarf an einem kompletten und vollständigem Techtree von Runde 11 besteht, kann ich Euch gerne mal den der Gilde schicken...
balouh
commented
12 years ago 1.) die IDs sind notwendig, da du in den Tabellen der Froschungs-Abhängigkeiten nur mit IDs arbeitest 2.) bisher war es so, dass für jede Stufe ein neues Gebäude angelegt wurde, sprich du hast beim Forschungslabor FLab Stufe 1-x gehabt (mit den jeweils unterschiedlichen Kosten und Bauzeiten). Da ja auf die neuen Parser umgestellt wurde, tritt hier natürlich das erste Problem auf, da die Zeiten iwie angepasst werden müssen (was gerade bei den FLabs aktuell der Fall ist) 3.) mit den jetzigen Änderungen in der Forschungstabelle ist der Forschungsbaum auch komplett
Zum Grundstock: Der Grundstock wird im Endeffekt nur für den dynamischen Techtree benötigt, damit man schauen kann, welches Gebäude/Schiff etc benötigt wird, wie der Weg dahin ist. Wird der Tree nicht benötigt, kann alles dynamisch eingelesen werden, es müssen lediglich die zum Start baubaren Gebs, die nicht durch eine Forschung baubar sind, eingefügt werden. Dies sind die Techteams, Hilfskisten, klEisenmine, klStahl, Zelt, Solarplatten ... Neu eingefügt wird aber afair noch nichts. Ich habe testweise vor ein oder 2 Wochen mal den content nicht geladen und es wurden weder Schiffe noch Gebs hinzugefügt. Die Forschungen klappen. Hinzu kommt ja noch das Problem, dass wir die Gebs und Schiffe zur Zeit nicht über die Adminseite verwalten können.
masel
commented
12 years ago Primary Key ist im Moment die fortlaufende id d.h. existiert ein Sitterauftrag mit id 1 (z.B. kleine Eisenmine) und es werden neue Gebs in die DB geladen kann die id 1 was anderes sein (z.B. ein kleines Chemwerk) und sich der Sitterauftrag entsprechend ändern. (in denen wird ja auf die jeweilige id verwiesen). Ist so passiert, was natürlich unschön ist. INSERT ... ON DUPLICATE KEY UPDATE mit nur einer numerischen id ändert daran gar nichts, die Eisenmine würde trotzdem zu einem Chemwerk updated. Mit einem Hash des ursprünglichen Gebnamens (der beim Parsen oder per Adminmenü neu eingegebenen (Stufen-)Gebs) wollte ich das eben verhindern. Und somit ermöglichen per einfachem INSERT ... ON DUPLICATE KEY UPDATE neue reinladen zu können.
Ob die MYSQL-DB als eindeutige id mit fortlaufenden Nummern oder Hashes arbeitet ist recht egal, natürlich müsste man das einmal in der ganzen IWDB ändern. Ich kann natürlich auch einem Updater so bauen der die Sitteraufträge auf eine eventuell geänderte id korrigiert. (Setzt voraus das keiner die Gebäude ändert und man die z.B. anhand des Namens neu zuordnen kann.)
Oder klar man stellt nur ein gewissen Grundstock (wie umfangreich auch immer) zur Verfügung, keine Updates und jede Ally macht eben selbst, geht natürlich auch.
Ich hab jedenfalls noch 2 IWDBs um die ich mich kümmer die noch Gebs und Forschungsdaten vom Rundenstart haben und das sind eben andere ids als in den zur Verfügung gestellten Datenbankauszügen jetzt. Ein schlichter Import der iwdb_content_changes.sql gibt dann die erwähnten Probleme mit vorhandenen Sitteraufträgen. Die 2 IWDBs könnte ich auch noch per Hand auf den Status von jetzt bringen, ist nicht das Problem. Aber wer die IWDB vom Rundenstart sonst noch verwendet mit wem wir keinen Kontakt haben weis ich nicht, vielleicht niemand.
balouh
commented
11 years ago ich denke, kann hier zu, oder?
masel
commented
11 years ago Denke schon. Evl könne man noch überlegen die Datenbankänderungen (also die iwdb_content_changes.sql und die iwdb_structure_changes.sql) in einer Datei zusammenzubringen weil die teils voneinander abhängen können. Gibt es da Vorteile einer Trennung? Imho ist das mit einer Datei organisatorisch einfacher zu handlen. Andere Meinungen dazu?
noch ein Beispiel nachreich:
doppelter "aktuellenews" Eintrag in der params Tabelle der erstens sinnlos ist und zweitens das erstellen eines Primary-Index verhindert also geht das nur in der Reihenfolge:
DELETE FROM prefix_params WHERE name = 'aktuellnews' LIMIT 1;
ALTER TABLE prefix_params ADD PRIMARY KEY ( name );
balouh
commented
11 years ago sehe ich wie du, die Änderungen in eine Datei
masel
commented
11 years ago Wobei einer der jetzt nicht unsere Daten verwendet (Gebäudedaten oder was weis ich) hätte dann ein Problem hmm.
masel
commented
11 years ago ach lassen wir das einfach erstmal so ^^
Wenn es im Moment eine Änderung an der Datenbankstruktur gibt, sind wir darauf angewiesen, dass der verantwortliche Coder auch entsprechend die iwdb.sql von Hand anpasst. Das ist auf Dauer nicht wirklich praktikabel oder sinnvoll zu machen. Z.b. müssen dann auf Entwicklerseite immer zwei Datenbanken parallel gepflegt werden (einmal die leere Version zum Export, und eine funktionisfähige zum Entwickeln). Auch ändert sich die immer unwichtiger Kleinkram, je nachdem wie die Datei exportiert wurde (phpMyAdmin, mysqldump, etc). Ein händisches Nacharbeiten ist also immer noch erforderlich oder zumindest sinnvoll.
Nun zur eigentlichen Frage ;-) Können wir das irgendwie sinnvoller gestalten ? Z.b. eine Basis iwdb.sql, und dann nur die Änderungen in einigen patch.sql Files ? Bei "Milestones" können die dann ja von Zeit zu Zeit wieder gemerged werden... Kennt ihr Tools die SQL Files vernünftig "diffen" können ? Ich hatte zwar mal so ein Ding angefangen, aber das ist noch vor dem Alpha Stadium
Deswegen mal die Frage in die Runde ...
Mac