nscunex hat geschrieben:1. bevor mit dem Update begonnen wird, sollte die Datenbankstruktur geprüft werden. Wenn es Abweichungen zum Standard gibt, sollte ein entsprechendes Fehlerprotokoll ausgegeben werden.
Damit kommt aber die große Frage: Was heißt denn "Abweichungen vom Standard". Das kann auch heißen, in der DB befinden sich weitere Views/Tabellen, die durch eine weiteres Plugin erzeugt wurden - ist das dann nicht auch eine Abweichung vom Standard? Das angleichen an einen "Standard" macht ja bspw. Typo3 (CMS), das dann aber keine Datenmigration kann (reiner Struktur abgleich), in der Java Persistence Welt, kenne ich eigentlich nur die Variante "Create", die zwar neue Strukturen aufbaut, aber nicht alte weg reist (außer Mann ist Wahnsinnig genug Drop-Create zu benutzen ...).
nscunex hat geschrieben:2. bei einem Updatefehler werden entsprechende Meldungen bezüglich des Updatefortschritts in einer Logdatei abgelegt.
Also bei meinen Tests mit JVerein (ich habe die Option implementiert für SEPA auch die externe Mitgliedsnummer nutzen zu können), habe ich die Fehler jeweils problemfrei aus dem Log lesen können. Das beim weiteren (zweiten, dritten) Aufruf die Fehler andere sind (weil bspw. ein Update nur teilweise gelaufen sind und dann doppelte Columns oder ähnliches auftreten sollte klar sein).
nscunex hat geschrieben:3. der Updatevorgang läuft transaktionsgesichert.
Die Idee ist gut, aber IMHO undurchführbar - die Updates von denen wir hier reden sind DDL Statements. Transaktionen an sich sind schon bei DML-Statements (SELECT, INSERT, DELETE) nicht überall verbreitet (MyISAM vs. InnoDB), Support für die transaktionelle Durchführung von DDL-Statements (CREATE, ALTER, MODIFIY, DROP) in Kombination mit weiteren DML-Aktionen in einer Transaktionen, ist bei H2 nicht unterstützt (aus der Docu zu CREATE TABLE:
This command commits an open transaction, except when using TRANSACTIONAL (only supported for temporary tables).)
Natürlich kann man das alle robust programmieren, aber wer macht es, wann, und wovon lebt der dann?
JVerein ist ganz sicher nicht die Eierlegendewollmilchsau, es tut aber seinen Dienst. Beruflich habe ich mit kommerziellen Produkten (andere Bereiche) zu tun, die zum Teil horende Summen kosten und selbst oberflächlich grobe Schnitzer haben, dagegen ist JVerein und die JVerein Codebasis ein Segen.
nscunex hat geschrieben:... denn Handarbeit ist mühselig und nicht für jeden Nutzer einfach durchführbar
Interessant wäre ja die Frage: Wie kamen die Fehler in die DB-Strukturen?!