Autoupdate: Unterschied zwischen den Versionen

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
 
Keine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:
//
// 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:
//  Verwirklichtes Konzept:
//
//
Zeile 42: Zeile 10:
//  post_event 'PLEASE_DISCONNECT';
//  post_event 'PLEASE_DISCONNECT';
// * auch einen event 'PLEASE_DOWN' schaffen, der den Applikationen signalisiert,
// * auch einen event 'PLEASE_DOWN' schaffen, der den Applikationen signalisiert,
//  das in wenigen Minuten heruntergefahren werden muss. z.B. Könnte so ein XMLRPC
//  das in wenigen Minuten heruntergefahren werden muss. z.B. K?e so ein XMLRPC
//  Server keine neuen Verbindungen mehr annehmen! '9998'
//  Server keine neuen Verbindungen mehr annehmen! '9998'
// * OrgaMon sollte dem Benutzer die Aufforderung zum Beenden anzeigen
// * OrgaMon sollte dem Benutzer die Aufforderung zum Beenden anzeigen
// * Update-Prozess von Orgamon: OrgaMon schreibt Batch, ruft den batch auf, beendet
// * Update-Prozess von Orgamon: OrgaMon schreibt Batch, ruft den batch auf, beendet
//  sich selbst. Der batch ruft sleep, um sicherzustellen das OrgaMon beendet ist.
//  sich selbst. Der batch ruft sleep, um sicherzustellen das OrgaMon beendet ist.
//  Danach das Setup, dieses überschreibt den exe, ruft diesem im Anschluss auf!
//  Danach das Setup, dieses ?hreibt den exe, ruft diesem im Anschluss auf!
// * Eine neue ftp/web-"Update?" Aktion sollte nachsehen können, ob Updates vorliegen!
// * Eine neue ftp/web-"Update?" Aktion sollte nachsehen k?n, ob Updates vorliegen!
//  spätestens bei Tagesabschluss sollte das gemacht werden!
//  spä´¥stens bei Tagesabschluss sollte das gemacht werden!
// * Ein Updateadmin sollte das downgeloadete Update für alle freischalten können.
// * Ein Updateadmin sollte das downgeloadete Update f?e freischalten k?n.
// * Szenario überlegen: Wie kann der Updateadmin ein "mörderisches" Update wieder
// * Szenario ?gen: Wie kann der Updateadmin ein "m?risches" Update wieder
//  entfernen will, er will sicherstellen dass alle wieder auf die alte Version
//  entfernen will, er will sicherstellen dass alle wieder auf die alte Version
//  zurückgehen, das autoupdate verhindern! OrgaMon darf nicht mehr "nerfen" das
//  zur?en, das autoupdate verhindern! OrgaMon darf nicht mehr "nerfen" das
//  eine neue Version vorliegt. Der Admin soll einfach "unstable" Revisions
//  eine neue Version vorliegt. Der Admin soll einfach "unstable" Revisions
//  markieren können. Beim Start sollten "zu neue" Orgamons eine Warnmeldung ausgeben
//  markieren k?n. Beim Start sollten "zu neue" Orgamons eine Warnmeldung ausgeben
//  bzw. gleich die richtige Version drüberinstallieren (Programmversion>Datenbank-
//  bzw. gleich die richtige Version dr?stallieren (Programmversion>Datenbank-
//  Version/empfohlene Version)
//  Version/empfohlene Version)
// * Ein Updateadmin sollte das fertig downgeloadete Update signalisiert bekommen
// * Ein Updateadmin sollte das fertig downgeloadete Update signalisiert bekommen
//  er gibt diese Version frei oder nicht.
//  er gibt diese Version frei oder nicht.
// * Während das Datenbank-Update noch läuft, muss verhindert werden dass sich
// * W䨲end das Datenbank-Update noch l䵦t, muss verhindert werden dass sich
//  Clients mit der Datenbank verbinden. Dies könnte einfach durch eine vorhandene
//  Clients mit der Datenbank verbinden. Dies k?e einfach durch eine vorhandene
//  "Sperr"-Datei im Anwendungsverzeichnis erfolgen. Es wird ein Warte-Dialog aus-
//  "Sperr"-Datei im Anwendungsverzeichnis erfolgen. Es wird ein Warte-Dialog aus-
//  geführt, bis das Update abgeschlossen ist.
//  gef?bis das Update abgeschlossen ist.
// * In einer zukünftigen Version könnte das DB-Update einfach mal versucht werden,
// * In einer zuk?en Version k?e das DB-Update einfach mal versucht werden,
//  dabei müsste aufgezeichnet werden, welche Update-Schritte durchliefen, und bei
//  dabei m?aufgezeichnet werden, welche Update-Schritte durchliefen, und bei
//  welchen es zur DB-Fehlermeldung "Object in use" kam. Kam es erstmalig zu diesem
//  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
//  Fehler, muss der down der anderen Clients erzwungen werden. (dadurch wird es

Version vom 19. September 2005, 08:06 Uhr

// 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?e 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 ?hreibt den exe, ruft diesem im Anschluss auf! // * Eine neue ftp/web-"Update?" Aktion sollte nachsehen k?n, ob Updates vorliegen! // spä´¥stens bei Tagesabschluss sollte das gemacht werden! // * Ein Updateadmin sollte das downgeloadete Update f?e freischalten k?n. // * Szenario ?gen: Wie kann der Updateadmin ein "m?risches" Update wieder // entfernen will, er will sicherstellen dass alle wieder auf die alte Version // zur?en, das autoupdate verhindern! OrgaMon darf nicht mehr "nerfen" das // eine neue Version vorliegt. Der Admin soll einfach "unstable" Revisions // markieren k?n. Beim Start sollten "zu neue" Orgamons eine Warnmeldung ausgeben // bzw. gleich die richtige Version dr?stallieren (Programmversion>Datenbank- // Version/empfohlene Version) // * Ein Updateadmin sollte das fertig downgeloadete Update signalisiert bekommen // er gibt diese Version frei oder nicht. // * W䨲end das Datenbank-Update noch l䵦t, muss verhindert werden dass sich // Clients mit der Datenbank verbinden. Dies k?e einfach durch eine vorhandene // "Sperr"-Datei im Anwendungsverzeichnis erfolgen. Es wird ein Warte-Dialog aus- // gef?bis das Update abgeschlossen ist. // * In einer zuk?en Version k?e das DB-Update einfach mal versucht werden, // dabei m?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! // *