Autoupdate
// 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! // *