Don't use labdas in unit tests at all unless it is strongly necessary.
Write a single method for each test case with plain code, if in needs to be
tested with different setup, pass parameters to this method and invoke it
multiple times. Take a look on existing unit tests for examples.
I changed execute(boolean autoCommit, SQLUnit... units) to re-open
connection and tests started to fail, but maybe I did something wrong.
Anyway, such method shouldn't exist, because it's hard to add some
additional operation (such as mentioned reconnection) to existing tests ad
debugging is also complicated.
This code throws OOME unless restore point creation is commented out:
Connection conn = DriverManager.getConnection("jdbc:h2:mem:1");
Statement stat = conn.createStatement();
stat.execute("CREATE TABLE TEST(ID BIGINT GENERATED ALWAYS AS IDENTITY
PRIMARY KEY, V BINARY VARYING)");
stat.execute("CREATE RESTORE POINT P");
PreparedStatement prepInsert = conn.prepareStatement("INSERT INTO TEST(V)
VALUES ?");
PreparedStatement prepDelete = conn.prepareStatement("DELETE FROM TEST");
for (;;) {
prepInsert.setBytes(1, new byte[1_000_000]);
prepInsert.executeUpdate();
prepDelete.executeUpdate();
}
This code throws General Error:
DeleteDbFiles.execute(".", "rptest1", false);
Connection conn = DriverManager.getConnection(
"jdbc:h2:./rptest1;DEFRAG_ALWAYS=TRUE");
Statement stat = conn.createStatement();
stat.execute("CREATE TABLE TEST(ID BIGINT GENERATED ALWAYS AS IDENTITY
PRIMARY KEY, V INT)");
PreparedStatement prepInsert = conn.prepareStatement("INSERT INTO TEST(V)
VALUES ?");
prepInsert.setInt(1, 1);
prepInsert.executeUpdate();
stat.execute("CREATE RESTORE POINT P");
for (int i = 2; i <= 100; i++) {
prepInsert.setInt(1, i);
prepInsert.executeUpdate();
}
conn.close();
conn = DriverManager.getConnection("jdbc:h2:./rptest1");
stat = conn.createStatement();
stat.execute("RESTORE TO POINT P");
ResultSet rs = stat.executeQuery("SELECT COUNT(*) FROM TEST");
rs.next();
System.out.println(rs.getLong(1));
It is possible to write a more complex code where RESTORE TO POINT will
silently restore to the wrong version. I think you can document that
database compaction may erase restore points, but in this case you need to
remove their metadata as well to prevent possibility to execute these
commands with outdated versions.
Because SCRIPT command can't export these restore points, it must be
documented.
You also need to document this functionality as experimental only.
I think content of INFORMATION_SCHEMA.RESTORE_POINTS shouldn't be visible
for regular users. Don't use MVCC in its documentation, this term only
confuses people.
What is a purpose of OLDEST_DATABASE_VERSION_TO_KEEP and why this field
isn't changed in newer restore points if older restore points were already
dropped?
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to h2-database+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/h2-database/efc90fa1-b322-4471-8c81-c1babbcef8bdn%40googlegroups.com.
