AutoPatch was born from the needs of using an agile development process while working on systems that have persistent storage. Without AutoPatch, developers usually can't afford the maintenance headache of their own database, and DBAs are required just to apply changes to all of the various environments a serious development effort requires.
The very application of database changes becomes an inefficient, error-prone, expensive process, all conspiring to discourage any refactoring that touches the model, or being a bottleneck when model changes are made.
AutoPatch solves this problem, completely.
With AutoPatch, an agile development process that requires a database change looks like this:
* Developer alters the model, which requires a change to the database
* Developer possibly consults a DBA, and develops a SQL patch against their personal database that implements the alteration
* Developer commits the patch to source control at the same time as they commit their dependent code
* Other developers' and environments' databases are automatically updated by AutoPatch the next time the new source is run
This represents streamlined environment maintenance, allowing developers to cheaply have their own databases and all databases to stay in synch with massively lower costs and no environment skew.
That's what AutoPatch does.
Clusters with one database? Multiple schemas? Logical migrations, instead of just DDL changes? Need to do something special/custom? Need to distribute your changes commercially? All without paying anything? No problem.
Very interesting approach!
"Apache Empire-db is an Open Source relational data persistence component which allows database vendor independent dynamic query definition as well as safe and simple data retrieval and updating. Compared to most other solutions like e.g. Hibernate, TopLink, iBATIS or JPA implementations, Empire-db takes a considerably different approach, with a special focus on compile-time safety, reduced redundancies and improved developer productivity."
Das Problem …
PHP-Scripte werden nach einer bestimmten Laufzeit abgebrochen (normalerweise nach 30 Sekunden), und so funktioniert ein Backup mit diversen Tools nur bis zu einer bestimmten Größe.
Braucht das Script länger als die 30 Sekunden, so wird es vom Server einfach abgebrochen, und man kommt nicht mehr an sein Backup heran. Gleiches gilt für das Wiedereinspielen eines Backups.
Wer einmal ein Dumpfile von Hand in viele kleinere Einzelabschnitte zerlegt hat, um eine Datenbank wieder herzustellen, der weiß genau, wovon wir reden.
MySQLDumper ist die Lösung …
MySQLDumper umgeht den Timeout-Error mit Hilfe eines kleinen Tricks: Er liest nur eine bestimmte Anzahl von Datensätzen aus der Tabelle aus, merkt sich, wie weit er gekommen ist, und ruft sich anschließend selbst auf. Dadurch erhält das Script bei jedem Aufruf wieder die vollen 30 Sekunden und umgeht so den Timeout-Error. Das gleiche Prinzip benutzt MySQLDumper auch beim Wiederherstellen der Daten.
MySQLDumper kann die Daten beim Sichern sofort packen. Auch das Wiederherstellungsscript kann direkt aus dieser gepackten Datei lesen, ohne dass sie auf dem Server entpackt werden muss! Natürlich kann man die Datei auch ungepackt lassen, aber spätestens beim Hochladen eines Backups weiß man dies zu schätzen.
DbFit is a set of FIT fixtures which enables FIT/FitNesse tests to execute directly against a database. This enables developers to manipulate database objects in a relational tabular form, making database testing and management much easier then with xUnit-style tools. The library is free to use, released under GNU GPL.