Strict Standards: Declaration of Walker_Page::start_lvl() should be compatible with Walker::start_lvl(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_Page::end_lvl() should be compatible with Walker::end_lvl(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_Page::start_el() should be compatible with Walker::start_el(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_Page::end_el() should be compatible with Walker::end_el(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1199

Strict Standards: Declaration of Walker_PageDropdown::start_el() should be compatible with Walker::start_el(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1244

Strict Standards: Declaration of Walker_Category::start_lvl() should be compatible with Walker::start_lvl(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_Category::end_lvl() should be compatible with Walker::end_lvl(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_Category::start_el() should be compatible with Walker::start_el(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_Category::end_el() should be compatible with Walker::end_el(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1391

Strict Standards: Declaration of Walker_CategoryDropdown::start_el() should be compatible with Walker::start_el(&$output) in /www/htdocs/v167612/wplog/wp-includes/classes.php on line 1442

Strict Standards: Redefining already defined constructor for class wpdb in /www/htdocs/v167612/wplog/wp-includes/wp-db.php on line 306

Strict Standards: Redefining already defined constructor for class WP_Object_Cache in /www/htdocs/v167612/wplog/wp-includes/cache.php on line 433
iFool » 2009 » Dezember

Archiv

Archiv für Dezember, 2009

HSQLDB nicht als “inMemory-DB” nutzen

16. Dezember 2009

Auch bei der Entwicklung einer Anwendung und den damit verbundenen Tests kann es recht lästig sein, immer wieder “zu Fuß” Testdaten eingeben zu müssen. Die von GRAILS automatisch verwendete HSQLDB ist in der Data-Source als inMemory-DB konfiguriert und daher gehen alle erfassten Daten bei jeder Beendigung der Anwendung verloren.

Zwar kann man durch entsprechende Einlassungen im Bootstrap auch Testdaten “beim Hochfahren” generierern, aber das ist für flexible Tests auch nicht so prickelnd, zumal die Erfassung über Programmierung auch Mühen bedeutet.

Eine gute Alternative bietet die Möglichkeit, einfach die HSQLDB-Datasource anzupassen:


 development {
  dataSource {
   dbCreate = "update" // one of 'create', 'create-drop','update'
   url = "jdbc:hsqldb:file:/temp/test/mydb;shutdown=true"
  }
 }

In diesem Beispiel auf einem PC mit Windows 7 wird beim ersten Start ein Verzeichnis C:\temp\test mit folgenden Files erstellt: mydb.lck, mydb.log, mydb.script und mydb.properties.  In den Textdateien mydb.script und mydb.log werden die Tabellendefinitionen und die Daten in lesbarer Form gespeichert. Beim Start der Anwendung wird dann jeweils aus diesen Textdateien wieder eine schnelle “inMemory-DB” aufgebaut. Während die Anwendung läuft werden DB-Änderungen in der *.log-Datei protokolliert, sodass die Daten auch bei einem Crash der Anwendung nicht verloren gehen können.

Die Verwendung von HSQLDB in Verbindung mit Textdeateien zur Speicherung der Daten ist eine bequeme und sofort Verfügbare Alternative für jeden GRAILS-Entwickler. Außerdem kann es auch eine Alternative für den Livebetrieb in Anwendungen mit kleinem Datenbestand sein (bei wenigen Hundert Datensätze etwa).

Allgemein, Groovy & Grails