> 1) Re-playing the 10+ Rails-style migrations that issue CREATE TABLE > commands to create foo's schema. Doing this once at the start takes > ~1/4th of the test runtime.
Applying 10 migrations is not a big deal right now, but on my last project, we had ~1,200 after a few years of being in production. Applying them all from 0 sucked, so, using pg at the time, we'd snapshot the dev database on each release, and then just pg_restore it and apply only the newest migrations. Although my current project is nothing that size, I'd like the setup to scale for that type of project. Instead of an in-memory H2 db, I tried using an embedded file-based H2 db, but that slowed down the tests by ~2-3x, to essentially postgres speeds. So, I need to stay with the in-memory db, but somehow figure out how to bootstrap a schema in to it. Looking at the existing backup tools, they seem to be for taking file-based dbs to zip files. Really all I need is a text dumb of the schema. It looks like I could just get the Schema, then iterate all of the TableDatas, Sequences, call getCreateSQL on each, then for each Row in the TableDatas, make an INSERT using each Value's getSQL() method. And save all of this to a "backup.sql" file. Hm, Constraints and Indexes too. Then on startup, just feed "backup.sql" into the memory db. It should be quick to restore just the text schema snapshot. Is there anything that does this now that I'm missing? Thanks, Stephen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/h2-database?hl=en -~----------~----~----~----~------~----~------~--~---
