Autoupdate

// // todo // // * Wenn OrgaMon von aussen beendet wird: wait "OrgaMon" to be down! OrgaMon sollte // einen "InsideTRN" Flag pflegen, damit erkannt werden kann, ob gerade eine wichtige // längere Aktion vorliegt. Er muss gewartet werden bis zu Ende gebucht ist. So dass // das Beenden von aussen nicht "kritisch" ist. Zumindest das eCommerce-Modul sollte so // etwas haben. // * Der UpdateAdmin verursacht das Signal, dass alle OrgaMon sich beenden sollten. // Er wartet, bis die User-Anzahl der Datenbank auf "1" (er selbst) abgesunken // ist oder max 25 Sekunden. (Gibt es für den SYSDBA die Möglichkeit USER // ja durch einen "shutdown" rauszuschmeissen!). // * Jede Metadata Modifikation sollte kurz prüfen können, ob das Statement selbst // in der Datenbank schon realisiert wurde oder nicht - es wäre cool, wenn eine // Wissensdatenbank 'Quell-Satements' automatisiert in Ziel-Statements umwandeln // könnte. // * Noch cooler, neben dem check auf ein Undo - also ein "extern" rollback // "one single step" <do it statement>: // -> check-statement:boolean; true: "schon erledigt", false "muss ich noch machen" // -> do-it-statement:boolean; wie gehabt // -> undo-it-statement:boolean; // * ./Updates Verzeichnis leeren! // * No-MetaDatachange (neues Feld in der Revisionstabelle): Soll anzeigen ob der aktuelle // Release-Sprung ohne Meta-Data Änderung möglich war? Dann gelten "ältere" Releases // als "auch lauffähig" da sie zumindest in der Datenbank keinen Schaden anrichten. // * Released: Ein Flag das gesetzt wird, wenn es diese Version aus einem der Standard // Release-Medien stammt. (Developer releases setzen dieses Flag nicht) // * Problem: Der Entwickler hat in die Rev-Tabelle schon eine neuere Rev Nummer eingetragen // diese aber noch nicht released, in so einem Fall sollte sich baseupdate mit einer // Release drunter begnügen oder: Der entwickler muss eine release machen, damit andere // weiterarbeiten können. // // Verwirklichtes Konzept: // // * In es ein metadata relevantes Update, so wird in der Tabelle Revision ein '9999' // eingetragen. Dieses bleibt solange bestehen, bis der Updatevorgang abgeschlossen // oder fehlgeschlagen ist. Connects sollten in dieser Zeit unterbleiben! // * Frisch connectierte OrgaMon sollten im Update-Check geparkt werden, bis // das db-update abgeschlossen ist. Es wird dabei im Sekundentakt immer wieder // nach dem Wert 9999 gesehen! // * Sieht die Datenbank beim insert den Wert '9999' so feuert sie den event // post_event 'PLEASE_DISCONNECT'; // * auch einen event 'PLEASE_DOWN' schaffen, der den Applikationen signalisiert, // das in wenigen Minuten heruntergefahren werden muss. z.B. Könnte so ein XMLRPC // Server keine neuen Verbindungen mehr annehmen! '9998' // * OrgaMon sollte dem Benutzer die Aufforderung zum Beenden anzeigen // * Update-Prozess von Orgamon: OrgaMon schreibt Batch, ruft den batch auf, beendet // sich selbst. Der batch ruft sleep, um sicherzustellen das OrgaMon beendet ist. // Danach das Setup, dieses überschreibt den exe, ruft diesem im Anschluss auf! // * Eine neue ftp/web-"Update?" Aktion sollte nachsehen können, ob Updates vorliegen! // spätestens bei Tagesabschluss sollte das gemacht werden! // * Ein Updateadmin sollte das downgeloadete Update für alle freischalten können. // * Szenario überlegen: Wie kann der Updateadmin ein "mörderisches" Update wieder // entfernen will, er will sicherstellen dass alle wieder auf die alte Version // zurückgehen, das autoupdate verhindern! OrgaMon darf nicht mehr "nerfen" das // eine neue Version vorliegt. Der Admin soll einfach "unstable" Revisions // markieren können. Beim Start sollten "zu neue" Orgamons eine Warnmeldung ausgeben // bzw. gleich die richtige Version drüberinstallieren (Programmversion>Datenbank- // Version/empfohlene Version) // * Ein Updateadmin sollte das fertig downgeloadete Update signalisiert bekommen // er gibt diese Version frei oder nicht. // * Während das Datenbank-Update noch läuft, muss verhindert werden dass sich // Clients mit der Datenbank verbinden. Dies könnte einfach durch eine vorhandene // "Sperr"-Datei im Anwendungsverzeichnis erfolgen. Es wird ein Warte-Dialog aus- // geführt, bis das Update abgeschlossen ist. // * In einer zukünftigen Version könnte das DB-Update einfach mal versucht werden, // dabei müsste aufgezeichnet werden, welche Update-Schritte durchliefen, und bei // welchen es zur DB-Fehlermeldung "Object in use" kam. Kam es erstmalig zu diesem // Fehler, muss der down der anderen Clients erzwungen werden. (dadurch wird es // zum kritischen Update!). Ab der ersten exception kann ja nun wieder angesetzt // werden! // * Die SQL-Scripts, die von Release zu Relase die Datenbank Struktur // hochziehen, nach aussen transparenter machen (in der !*_Info.html!), da doch das // Interesse an der Datenbank-Struktur bei siemens da zu sein scheint. // die Datei befindet sich im Verzeichnis "MyApplicationPath". format: // * Nach manchen SQL-Script Befehlen wird "reconnect" notwendig, dies kann im // hebu - Projekt nachgewiesen werden. Ev. mal einen Test-Case daraus machen! // *