You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The common way tests get run in NetBSD is by starting a fresh virtual machine with a new copy of the system, running the tests inside it, and then extracting the resulting database from the virtual machine. These results need to be archived later alongside other tests so that the historical data can be served to users.
A way to achieve this, which could be beneficial for backup purposes as well, is to implement a mechanism to export the contents of a database and import them later into another one. In the particular use case above, the database generated within the virtual machine would contain a single action, which would be exported first and then imported into the "global" database.
This implies that, if the target database is not empty, all identifiers need to be rewritten to avoid collisions.
The intermediate representation of the exported data would be either SQL statements or some higher-level description using Lua tables. An alternative would be to just have a db-import that reads from another SQLite database directly, but somehow at the moment I think that the textual intermediate representation is worth it. Needs more thought.
Not applicable any longer after 0.9. The historical database has been replaced with per-test results files, which implicitly provide this functionality.
From julio@meroh.net on July 16, 2013 07:43:45
The common way tests get run in NetBSD is by starting a fresh virtual machine with a new copy of the system, running the tests inside it, and then extracting the resulting database from the virtual machine. These results need to be archived later alongside other tests so that the historical data can be served to users.
A way to achieve this, which could be beneficial for backup purposes as well, is to implement a mechanism to export the contents of a database and import them later into another one. In the particular use case above, the database generated within the virtual machine would contain a single action, which would be exported first and then imported into the "global" database.
This implies that, if the target database is not empty, all identifiers need to be rewritten to avoid collisions.
The intermediate representation of the exported data would be either SQL statements or some higher-level description using Lua tables. An alternative would be to just have a db-import that reads from another SQLite database directly, but somehow at the moment I think that the textual intermediate representation is worth it. Needs more thought.
Original issue: http://code.google.com/p/kyua/issues/detail?id=62
The text was updated successfully, but these errors were encountered: