@@ -1667,492 +1667,546 @@ Fixed a deadlock when updating LOB's concurrently. See TestLob.testDeadlock2().
...
@@ -1667,492 +1667,546 @@ Fixed a deadlock when updating LOB's concurrently. See TestLob.testDeadlock2().
Fixed a deadlock related to very large temporary result sets.
Fixed a deadlock related to very large temporary result sets.
@changelog_1010_li
@changelog_1010_li
Add "-list" command line option to Shell tool so that result-list-mode can be triggered when reading from a file
Add "-list" command line option to Shell tool so that result-list-mode can be triggered when reading from a file.
@changelog_1011_h2
@changelog_1011_li
Version 1.3.172 (2013-05-25)
Issue 474: H2 Mysql Compatibility code fails to ignore "COMMENT" in CREATE TABLE, patch from Aaron Azeckoski.
@changelog_1012_li
@changelog_1012_li
Referential integrity: when adding a referential integrity constraint failed, and if creating the constraint automatically created an index, this index was not removed.
Issue 476: Broken link in jaqu.html
@changelog_1013_li
@changelog_1013_li
The auto-analyze feature now only reads 1000 rows per table instead of 10000.
Fix potential UTF8 encoding issue in org.h2.store.FileStore, reported by Juerg Spiess.
@changelog_1014_li
@changelog_1014_li
The optimization for IN(...) queries combined with OR could result in a strange exception of the type "column x must be included in the group by list".
Improve error message when check constraint is broken, test case from Gili (cowwoc).
@changelog_1015_li
@changelog_1015_li
Issue 454: Use Charset for type-safety.
Improve error message when we have a unique constraint violation, displays the offending key in the error message.
@changelog_1016_li
@changelog_1016_li
Queries with both LIMIT and OFFSET could throw an IllegalArgumentException.
Issue 478: Support for "SHOW TRANSACTION ISOLATION LEVEL", patch from Andrew Franklin.
@changelog_1017_li
@changelog_1017_li
MVStore: multiple issues were fixed: 460, 461, 462, 464, 466.
Issue 475: PgServer: add support for CancelRequest, patch from Andrew Franklin.
@changelog_1018_li
@changelog_1018_li
MVStore: larger stores (multiple GB) are now much faster.
Issue 473: PgServer missing -key option, patch from Andrew Franklin.
@changelog_1019_li
@changelog_1019_li
When using local temporary tables and not dropping them manually before closing the session, and then killing the process could result in a database that couldn't be opened (except when using the recover tool).
Issue 471: CREATE VIEW does not check user rights, patch from Andrew Franklin.
@changelog_1020_li
@changelog_1020_li
Support TRUNC(timestamp) for improved Oracle compatibility.
Issue 477: PgServer binary transmission of query params is unimplemented, patch from Andrew Franklin.
@changelog_1021_li
@changelog_1021_li
Add support for CREATE TABLE TEST (ID BIGSERIAL) for PostgreSQL compatibility. Patch from Jesse Long.
Issue 479: Support for SUBSTRING without a FROM condition, patch from Andrew Franklin.
@changelog_1022_li
@changelog_1022_li
Add new collation command SET BINARY_COLLATION UNSIGNED, helps with people testing BINARY columns in MySQL mode.
Issue 472: PgServer does not work with any recent Postgres JDBC driver, patch from Andrew Franklin.
@changelog_1023_li
@changelog_1023_li
Issue 453: ABBA race conditions in TABLE LINK connection sharing.
Add syntax for passing additional parameters into custom TableEngine implementations.
@changelog_1024_li
@changelog_1024_li
Issue 449: Postgres Serial data type should not automatically be marked as primary key
Issue 480: Bugfix post issue #475, #477, patch from Andrew Franklin.
@changelog_1025_li
@changelog_1025_li
Issue 406: Support "select h2version()"
Issue 481: Further extensions to PgServer to support better support PG JDBC, patch from Andrew Franklin.
@changelog_1026_li
@changelog_1026_li
Issue 389: When there is a multi-column primary key, H2 does not seem to always pick the right index
Add support for spatial datatype GEOMETRY.
@changelog_1027_li
@changelog_1027_li
Issue 305: Implement SELECT ... FOR FETCH ONLY
Add support for in-memory spatial index.
@changelog_1028_li
@changelog_1028_li
change the PageStore#changeCount field from an int to a long, to cope with databases with very high transaction rates.
@changelog_1029_h2
Version 1.3.172 (2013-05-25)
@changelog_1030_li
Referential integrity: when adding a referential integrity constraint failed, and if creating the constraint automatically created an index, this index was not removed.
@changelog_1031_li
The auto-analyze feature now only reads 1000 rows per table instead of 10000.
@changelog_1032_li
The optimization for IN(...) queries combined with OR could result in a strange exception of the type "column x must be included in the group by list".
@changelog_1033_li
Issue 454: Use Charset for type-safety.
@changelog_1034_li
Queries with both LIMIT and OFFSET could throw an IllegalArgumentException.
@changelog_1035_li
MVStore: multiple issues were fixed: 460, 461, 462, 464, 466.
@changelog_1036_li
MVStore: larger stores (multiple GB) are now much faster.
@changelog_1037_li
When using local temporary tables and not dropping them manually before closing the session, and then killing the process could result in a database that couldn't be opened (except when using the recover tool).
@changelog_1038_li
Support TRUNC(timestamp) for improved Oracle compatibility.
@changelog_1039_li
Add support for CREATE TABLE TEST (ID BIGSERIAL) for PostgreSQL compatibility. Patch from Jesse Long.
@changelog_1040_li
Add new collation command SET BINARY_COLLATION UNSIGNED, helps with people testing BINARY columns in MySQL mode.
@changelog_1041_li
Issue 453: ABBA race conditions in TABLE LINK connection sharing.
@changelog_1042_li
Issue 449: Postgres Serial data type should not automatically be marked as primary key
@changelog_1043_li
Issue 406: Support "select h2version()"
@changelog_1044_li
Issue 389: When there is a multi-column primary key, H2 does not seem to always pick the right index
@changelog_1045_li
Issue 305: Implement SELECT ... FOR FETCH ONLY
@changelog_1046_li
Issue 274: Sybase/MSSQLServer compatibility - Add GETDATE and CHARINDEX system functions
Issue 274: Sybase/MSSQLServer compatibility - Add GETDATE and CHARINDEX system functions
@changelog_1029_li
@changelog_1047_li
Issue 274: Sybase/MSSQLServer compatibility - swap parameters of CONVERT function.
Issue 274: Sybase/MSSQLServer compatibility - swap parameters of CONVERT function.
@changelog_1030_li
@changelog_1048_li
Issue 274: Sybase/MSSQLServer compatibility - support index clause e.g. "select * from test (index table1_index)"
Issue 274: Sybase/MSSQLServer compatibility - support index clause e.g. "select * from test (index table1_index)"
@changelog_1031_li
@changelog_1049_li
Fix bug in Optimizing SELECT * FROM A WHERE X=1 OR X=2 OR X=3 into SELECT * FROM A WHERE X IN (1,2,3)
Fix bug in Optimizing SELECT * FROM A WHERE X=1 OR X=2 OR X=3 into SELECT * FROM A WHERE X IN (1,2,3)
@changelog_1032_li
@changelog_1050_li
Issue 442: Groovy patch for SourceCompiler (function ALIAS)
Issue 442: Groovy patch for SourceCompiler (function ALIAS)
@changelog_1033_li
@changelog_1051_li
Issue 459: Improve LOB documentation
Issue 459: Improve LOB documentation
@changelog_1034_h2
@changelog_1052_h2
Version 1.3.171 (2013-03-17)
Version 1.3.171 (2013-03-17)
@changelog_1035_li
@changelog_1053_li
Security: the TCP server did not correctly restrict access rights of clients in some cases. This was specially a problem when using the flag "tcpAllowOthers".
Security: the TCP server did not correctly restrict access rights of clients in some cases. This was specially a problem when using the flag "tcpAllowOthers".
@changelog_1036_li
@changelog_1054_li
H2 Console: the session timeout can now be configured using the system property "h2.consoleTimeout".
H2 Console: the session timeout can now be configured using the system property "h2.consoleTimeout".
@changelog_1037_li
@changelog_1055_li
Issue 431: Improved compatibility with MySQL: support for "ENGINE=InnoDB charset=UTF8" when creating a table.
Issue 431: Improved compatibility with MySQL: support for "ENGINE=InnoDB charset=UTF8" when creating a table.
@changelog_1038_li
@changelog_1056_li
Issue 249: Improved compatibility with MySQL in the MySQL mode: now the methods DatabaseMetaData methods stores*Case*Identifiers return the same as MySQL when using the MySQL mode.
Issue 249: Improved compatibility with MySQL in the MySQL mode: now the methods DatabaseMetaData methods stores*Case*Identifiers return the same as MySQL when using the MySQL mode.
@changelog_1039_li
@changelog_1057_li
Issue 434: H2 Console didn't work in the Chrome browser due to a wrong viewport argument.
Issue 434: H2 Console didn't work in the Chrome browser due to a wrong viewport argument.
@changelog_1040_li
@changelog_1058_li
There was a possibility that the .lock.db file was not deleted when the database was closed, which could slow down opening the database.
There was a possibility that the .lock.db file was not deleted when the database was closed, which could slow down opening the database.
@changelog_1041_li
@changelog_1059_li
The SQL script generated by the "script" command contained inconsistent newlines on Windows.
The SQL script generated by the "script" command contained inconsistent newlines on Windows.
@changelog_1042_li
@changelog_1060_li
When using trace level 4 (SLF4J) in the server mode, a directory "trace.db" and an empty file was created on the client side. This is no longer made.
When using trace level 4 (SLF4J) in the server mode, a directory "trace.db" and an empty file was created on the client side. This is no longer made.
@changelog_1043_li
@changelog_1061_li
Optimize IN(...) queries: there was a bug in version 1.3.170 if the type of the left hand side didn't match the type of the right hand side. Fixed.
Optimize IN(...) queries: there was a bug in version 1.3.170 if the type of the left hand side didn't match the type of the right hand side. Fixed.
@changelog_1044_li
@changelog_1062_li
Optimize IN(...) queries: there was a bug in version 1.3.170 for comparison of the type "X IN(NULL, NULL)". Fixed.
Optimize IN(...) queries: there was a bug in version 1.3.170 for comparison of the type "X IN(NULL, NULL)". Fixed.
@changelog_1045_li
@changelog_1063_li
Timestamps with timezone that were passed as a string were not always converted correctly. For example "2012-11-06T23:00:00.000Z" was converted to "2012-11-06" instead of to "2012-11-07" in the timezone CET. Thanks a lot to Steve Hruda for reporting the problem!
Timestamps with timezone that were passed as a string were not always converted correctly. For example "2012-11-06T23:00:00.000Z" was converted to "2012-11-06" instead of to "2012-11-07" in the timezone CET. Thanks a lot to Steve Hruda for reporting the problem!
@changelog_1046_li
@changelog_1064_li
New table engine "org.h2.mvstore.db.MVTableEngine" that internally uses the MVStore to persist data. To try it out, append ";DEFAULT_TABLE_ENGINE=org.h2.mvstore.db.MVTableEngine" to the database URL. This is still very experimental, and many features are not supported yet. The data is stored in a file with the suffix ".mv.db".
New table engine "org.h2.mvstore.db.MVTableEngine" that internally uses the MVStore to persist data. To try it out, append ";DEFAULT_TABLE_ENGINE=org.h2.mvstore.db.MVTableEngine" to the database URL. This is still very experimental, and many features are not supported yet. The data is stored in a file with the suffix ".mv.db".
@changelog_1047_li
@changelog_1065_li
New connection setting "DEFAULT_TABLE_ENGINE" to use a specific table engine if none is set explicitly. This is to simplify testing the MVStore table engine.
New connection setting "DEFAULT_TABLE_ENGINE" to use a specific table engine if none is set explicitly. This is to simplify testing the MVStore table engine.
@changelog_1048_li
@changelog_1066_li
MVStore: encrypted stores are now supported. Only standardized algorithms are used: PBKDF2, SHA-256, XTS-AES, AES-128.
MVStore: encrypted stores are now supported. Only standardized algorithms are used: PBKDF2, SHA-256, XTS-AES, AES-128.
@changelog_1049_li
@changelog_1067_li
MVStore: improved API thanks to Simo Tripodi.
MVStore: improved API thanks to Simo Tripodi.
@changelog_1050_li
@changelog_1068_li
MVStore: maps can now be renamed.
MVStore: maps can now be renamed.
@changelog_1051_li
@changelog_1069_li
MVStore: store the file header also at the end of each chunk, which results in a further reduced number of write operations.
MVStore: store the file header also at the end of each chunk, which results in a further reduced number of write operations.
@changelog_1052_li
@changelog_1070_li
MVStore: a map implementation that supports concurrent operations.
MVStore: a map implementation that supports concurrent operations.
@changelog_1053_li
@changelog_1071_li
MVStore: unified exception handling; the version is included in the messages.
MVStore: unified exception handling; the version is included in the messages.
@changelog_1054_li
@changelog_1072_li
MVStore: old data is now retained for 45 seconds by default.
MVStore: old data is now retained for 45 seconds by default.
@changelog_1055_li
@changelog_1073_li
MVStore: compress is now disabled by default, and can be enabled on request.
MVStore: compress is now disabled by default, and can be enabled on request.
@changelog_1056_li
@changelog_1074_li
Support ALTER TABLE ADD ... AFTER. Patch from Andrew Gaul (argaul at gmail.com). Fixes issue 401.
Support ALTER TABLE ADD ... AFTER. Patch from Andrew Gaul (argaul at gmail.com). Fixes issue 401.
@changelog_1057_li
@changelog_1075_li
Improved OSGi support. H2 now registers itself as a DataSourceFactory service. Fixes issue 365.
Improved OSGi support. H2 now registers itself as a DataSourceFactory service. Fixes issue 365.
@changelog_1058_li
@changelog_1076_li
Add a DISK_SPACE_USED system function. Fixes issue 270.
Add a DISK_SPACE_USED system function. Fixes issue 270.
@changelog_1059_li
@changelog_1077_li
Fix a compile-time ambiguity when compiling with JDK7, thanks to a patch from Lukas Eder.
Fix a compile-time ambiguity when compiling with JDK7, thanks to a patch from Lukas Eder.
@changelog_1060_li
@changelog_1078_li
Supporting dropping an index for Lucene full-text indexes.
Supporting dropping an index for Lucene full-text indexes.
@changelog_1061_li
@changelog_1079_li
Optimized performance for SELECT ... ORDER BY X LIMIT Y OFFSET Z queries for in-memory databases using partial sort (by Sergi Vladykin).
Optimized performance for SELECT ... ORDER BY X LIMIT Y OFFSET Z queries for in-memory databases using partial sort (by Sergi Vladykin).
@changelog_1062_li
@changelog_1080_li
Experimental off-heap memory storage engine "nioMemFS:" and "nioMemLZF:", suggestion from Mark Addleman.
Experimental off-heap memory storage engine "nioMemFS:" and "nioMemLZF:", suggestion from Mark Addleman.
@changelog_1063_li
@changelog_1081_li
Issue 438: JdbcDatabaseMetaData.getSchemas() is no longer supported as of 1.3.169.
Issue 438: JdbcDatabaseMetaData.getSchemas() is no longer supported as of 1.3.169.
@changelog_1064_li
@changelog_1082_li
MySQL compatibility: support for ALTER TABLE tableName MODIFY [COLUMN] columnName columnDef. Patch from Ville Koskela.
MySQL compatibility: support for ALTER TABLE tableName MODIFY [COLUMN] columnName columnDef. Patch from Ville Koskela.
@changelog_1065_li
@changelog_1083_li
Issue 404: SHOW COLUMNS FROM tableName does not work with ALLOW_LITERALS=NUMBERS.
Issue 404: SHOW COLUMNS FROM tableName does not work with ALLOW_LITERALS=NUMBERS.
@changelog_1066_li
@changelog_1084_li
Throw an explicit error to make it clear we don't support the TRIGGER combination of SELECT and FOR EACH ROW.
Throw an explicit error to make it clear we don't support the TRIGGER combination of SELECT and FOR EACH ROW.
@changelog_1067_li
@changelog_1085_li
Issue 439: Utils.sortTopN does not handle single-element arrays.
Issue 439: Utils.sortTopN does not handle single-element arrays.
@changelog_1068_h2
@changelog_1086_h2
Version 1.3.170 (2012-11-30)
Version 1.3.170 (2012-11-30)
@changelog_1069_li
@changelog_1087_li
Issue 407: The TriggerAdapter didn't work with CLOB and BLOB columns.
Issue 407: The TriggerAdapter didn't work with CLOB and BLOB columns.
@changelog_1070_li
@changelog_1088_li
PostgreSQL compatibility: support for data types BIGSERIAL and SERIAL as an alias for AUTO_INCREMENT.
PostgreSQL compatibility: support for data types BIGSERIAL and SERIAL as an alias for AUTO_INCREMENT.
@changelog_1071_li
@changelog_1089_li
Issue 417: H2 Console: the web session timeout didn't work, resulting in a memory leak. This was only a problem if the H2 Console was run for a long time and many sessions were opened.
Issue 417: H2 Console: the web session timeout didn't work, resulting in a memory leak. This was only a problem if the H2 Console was run for a long time and many sessions were opened.
@changelog_1072_li
@changelog_1090_li
Issue 412: Running the Server tool with just the option "-browser" will now log a warning.
Issue 412: Running the Server tool with just the option "-browser" will now log a warning.
@changelog_1073_li
@changelog_1091_li
Issue 411: CloseWatcher registration was not concurrency-safe.
Issue 411: CloseWatcher registration was not concurrency-safe.
@changelog_1074_li
@changelog_1092_li
MySQL compatibility: support for CONCAT_WS. Thanks a lot to litailang for the patch!
MySQL compatibility: support for CONCAT_WS. Thanks a lot to litailang for the patch!
@changelog_1075_li
@changelog_1093_li
PostgreSQL compatibility: support for EXTRACT(WEEK FROM dateColumn). Thanks to Prashant Bhat for the patch!
PostgreSQL compatibility: support for EXTRACT(WEEK FROM dateColumn). Thanks to Prashant Bhat for the patch!
@changelog_1076_li
@changelog_1094_li
Fix for a bug where we would sometimes use the wrong unique constraint to validate foreign key constraints.
Fix for a bug where we would sometimes use the wrong unique constraint to validate foreign key constraints.
@changelog_1077_li
@changelog_1095_li
Support BOM at the beginning of files for the RUNSCRIPT command
Support BOM at the beginning of files for the RUNSCRIPT command
@changelog_1078_li
@changelog_1096_li
Fix in calling SET @X = IDENTITY() where it would return NULL incorrectly
Fix in calling SET @X = IDENTITY() where it would return NULL incorrectly
@changelog_1079_li
@changelog_1097_li
Fix ABBA deadlock between adding a constraint and the H2-Log-Writer thread.
Fix ABBA deadlock between adding a constraint and the H2-Log-Writer thread.
@changelog_1080_li
@changelog_1098_li
Optimize IN(...) queries where the values are constant and of the same type.
Optimize IN(...) queries where the values are constant and of the same type.
@changelog_1081_li
@changelog_1099_li
Restore tool: the parameter "quiet" was not used and is now removed.
Restore tool: the parameter "quiet" was not used and is now removed.
@changelog_1082_li
@changelog_1100_li
Fix ConcurrentModificationException when creating tables and executing SHOW TABLES in parallel. Reported by Viktor Voytovych.
Fix ConcurrentModificationException when creating tables and executing SHOW TABLES in parallel. Reported by Viktor Voytovych.
@changelog_1083_li
@changelog_1101_li
Serialization is now pluggable using the system property "h2.javaObjectSerializer". Thanks to Sergi Vladykin for the patch!
Serialization is now pluggable using the system property "h2.javaObjectSerializer". Thanks to Sergi Vladykin for the patch!
@changelog_1084_h2
@changelog_1102_h2
Version 1.3.169 (2012-09-09)
Version 1.3.169 (2012-09-09)
@changelog_1085_li
@changelog_1103_li
The default jar file is now compiled for Java 6.
The default jar file is now compiled for Java 6.
@changelog_1086_li
@changelog_1104_li
The new jar file will probably not end up in the central Maven repository in the next few weeks because Sonatype has disabled automatic synchronization from SourceForge (which they call 'legacy sync' now). It will probably take some time until this is sorted out. The H2 jar files are deployed to http://h2database.com/m2-repo/com/h2database/h2/maven-metadata.xml and http://hsql.sourceforge.net/m2-repo/com/h2database/h2/maven-metadata.xml as usual.
The new jar file will probably not end up in the central Maven repository in the next few weeks because Sonatype has disabled automatic synchronization from SourceForge (which they call 'legacy sync' now). It will probably take some time until this is sorted out. The H2 jar files are deployed to http://h2database.com/m2-repo/com/h2database/h2/maven-metadata.xml and http://hsql.sourceforge.net/m2-repo/com/h2database/h2/maven-metadata.xml as usual.
@changelog_1087_li
@changelog_1105_li
A part of the documentation and the H2 Console has been changed to support the Apple retina display.
A part of the documentation and the H2 Console has been changed to support the Apple retina display.
@changelog_1088_li
@changelog_1106_li
The CreateCluster tool could not be used if the source database contained a CLOB or BLOB. The root cause was that the TCP server did not synchronize on the session, which caused a problem when using the exclusive mode.
The CreateCluster tool could not be used if the source database contained a CLOB or BLOB. The root cause was that the TCP server did not synchronize on the session, which caused a problem when using the exclusive mode.
@changelog_1089_li
@changelog_1107_li
Statement.getQueryTimeout(): only the first call to this method will query the database. If the query timeout was changed in another way than calling setQueryTimeout, this method will always return the last value. This was changed because Hibernate calls getQueryTimeout() a lot.
Statement.getQueryTimeout(): only the first call to this method will query the database. If the query timeout was changed in another way than calling setQueryTimeout, this method will always return the last value. This was changed because Hibernate calls getQueryTimeout() a lot.
@changelog_1090_li
@changelog_1108_li
Issue 416: PreparedStatement.setNString throws AbstractMethodError. All implemented JDBC 4 methods that don't break compatibility with Java 5 are now included in the default jar file.
Issue 416: PreparedStatement.setNString throws AbstractMethodError. All implemented JDBC 4 methods that don't break compatibility with Java 5 are now included in the default jar file.
@changelog_1091_li
@changelog_1109_li
Issue 414: for some functions, the parameters were evaluated twice (for example "char(nextval(..))" ran "nextval(..)" twice).
Issue 414: for some functions, the parameters were evaluated twice (for example "char(nextval(..))" ran "nextval(..)" twice).
@changelog_1092_li
@changelog_1110_li
The ResultSetMetaData methods getSchemaName and getTableName could return null instead of "" (an empty string) as specified in the JDBC API.
The ResultSetMetaData methods getSchemaName and getTableName could return null instead of "" (an empty string) as specified in the JDBC API.
@changelog_1093_li
@changelog_1111_li
Added compatibility for "SET NAMES" query in MySQL compatibility mode.
Added compatibility for "SET NAMES" query in MySQL compatibility mode.
@changelog_1094_h2
@changelog_1112_h2
Version 1.3.168 (2012-07-13)
Version 1.3.168 (2012-07-13)
@changelog_1095_li
@changelog_1113_li
The message "Transaction log could not be truncated" was sometimes written to the .trace.db file even if there was no problem truncating the transaction log.
The message "Transaction log could not be truncated" was sometimes written to the .trace.db file even if there was no problem truncating the transaction log.
@changelog_1096_li
@changelog_1114_li
New system property "h2.serializeJavaObject" (default: true) that allows to disable serializing Java objects, so that the objects compareTo and toString methods can be used.
New system property "h2.serializeJavaObject" (default: true) that allows to disable serializing Java objects, so that the objects compareTo and toString methods can be used.
@changelog_1097_li
@changelog_1115_li
Dylan has translated the H2 Console tool to Korean. Thanks a lot!
Dylan has translated the H2 Console tool to Korean. Thanks a lot!
@changelog_1098_li
@changelog_1116_li
Executing the statement CREATE INDEX IF ALREADY EXISTS if the index already exists no longer fails for a read only database.
Executing the statement CREATE INDEX IF ALREADY EXISTS if the index already exists no longer fails for a read only database.
@changelog_1099_li
@changelog_1117_li
MVCC: concurrently updating a row could result in the row to appear deleted in the second connection, if there are multiple unique indexes (or a primary key and at least one unique index). Thanks a lot to Teruo for the patch!
MVCC: concurrently updating a row could result in the row to appear deleted in the second connection, if there are multiple unique indexes (or a primary key and at least one unique index). Thanks a lot to Teruo for the patch!
@changelog_1100_li
@changelog_1118_li
Fulltext search: in-memory Lucene indexes are now supported.
Fulltext search: in-memory Lucene indexes are now supported.
@changelog_1101_li
@changelog_1119_li
Fulltext search: UUID primary keys are now supported.
Fulltext search: UUID primary keys are now supported.
@changelog_1102_li
@changelog_1120_li
Apache Tomcat 7.x will now longer log a warning when unloading the web application, if using a connection pool.
Apache Tomcat 7.x will now longer log a warning when unloading the web application, if using a connection pool.
@changelog_1103_li
@changelog_1121_li
H2 Console: support the Midori browser (for Debian / Raspberry Pi)
H2 Console: support the Midori browser (for Debian / Raspberry Pi)
@changelog_1104_li
@changelog_1122_li
When opening a remote session, don't open a temporary file if the trace level is set to zero
When opening a remote session, don't open a temporary file if the trace level is set to zero
@changelog_1105_li
@changelog_1123_li
Use HMAC for authenticating remote LOB id's, removing the need for maintaining a cache, and removing the limit on the number of LOBs per result set.
Use HMAC for authenticating remote LOB id's, removing the need for maintaining a cache, and removing the limit on the number of LOBs per result set.
@changelog_1106_li
@changelog_1124_li
H2 Console: HTML and XML documents can now be edited in an updatable result set. There is (limited) support for editing multi-line documents.
H2 Console: HTML and XML documents can now be edited in an updatable result set. There is (limited) support for editing multi-line documents.
@changelog_1107_h2
@changelog_1125_h2
Version 1.3.167 (2012-05-23)
Version 1.3.167 (2012-05-23)
@changelog_1108_li
@changelog_1126_li
H2 Console: when editing a row, an empty varchar column was replaced with a single space.
H2 Console: when editing a row, an empty varchar column was replaced with a single space.
@changelog_1109_li
@changelog_1127_li
Lukas Eder has updated the jOOQ documentation.
Lukas Eder has updated the jOOQ documentation.
@changelog_1110_li
@changelog_1128_li
Some nested joins could not be executed, for example: select * from (select * from (select * from a) a right join b b) c;
Some nested joins could not be executed, for example: select * from (select * from (select * from a) a right join b b) c;
@changelog_1111_li
@changelog_1129_li
MS SQL Server compatibility: ISNULL is now an alias for IFNULL.
MS SQL Server compatibility: ISNULL is now an alias for IFNULL.
@changelog_1112_li
@changelog_1130_li
Terrence Huang has completed the translation of the H2 Console tool to Chinese. Thanks a lot!
Terrence Huang has completed the translation of the H2 Console tool to Chinese. Thanks a lot!
@changelog_1113_li
@changelog_1131_li
Server mode: the number of CLOB / BLOB values that were cached on the server is now the maximum of: 5 times the SERVER_RESULT_SET_FETCH_SIZE (which is 100 by default), and SysProperties.SERVER_CACHED_OBJECTS.
Server mode: the number of CLOB / BLOB values that were cached on the server is now the maximum of: 5 times the SERVER_RESULT_SET_FETCH_SIZE (which is 100 by default), and SysProperties.SERVER_CACHED_OBJECTS.
@changelog_1114_li
@changelog_1132_li
In the trace file, the query execution time was incorrect in some cases, specially for the statement SET TRACE_LEVEL_FILE 2.
In the trace file, the query execution time was incorrect in some cases, specially for the statement SET TRACE_LEVEL_FILE 2.
@changelog_1115_li
@changelog_1133_li
The feature LOG_SIZE_LIMIT that was introduced in version 1.3.165 did not always work correctly (specially with regards to multithreading) and has been removed. The message "Transaction log could not be truncated" is still written to the .trace.db file if required.
The feature LOG_SIZE_LIMIT that was introduced in version 1.3.165 did not always work correctly (specially with regards to multithreading) and has been removed. The message "Transaction log could not be truncated" is still written to the .trace.db file if required.
@changelog_1116_li
@changelog_1134_li
Then reading from a resource using the prefix "classpath:", the ContextClassLoader is now used if the resource can't be read otherwise.
Then reading from a resource using the prefix "classpath:", the ContextClassLoader is now used if the resource can't be read otherwise.
@changelog_1117_li
@changelog_1135_li
DatabaseEventListener now calls setProgress whenever a statement starts and ends.
DatabaseEventListener now calls setProgress whenever a statement starts and ends.
@changelog_1118_li
@changelog_1136_li
DatabaseEventListener now calls setProgress periodically while a statement is running.
DatabaseEventListener now calls setProgress periodically while a statement is running.
@changelog_1119_li
@changelog_1137_li
The table INFORMATION_SCHEMA.FUNCTION_ALIASES now includes a column TYPE_NAME.
The table INFORMATION_SCHEMA.FUNCTION_ALIASES now includes a column TYPE_NAME.
@changelog_1120_li
@changelog_1138_li
Issue 378: when using views, the wrong values were bound to a parameter in some cases.
Issue 378: when using views, the wrong values were bound to a parameter in some cases.
@changelog_1121_li
@changelog_1139_li
Terrence Huang has translated the error messages to Chinese. Thanks a lot!
Terrence Huang has translated the error messages to Chinese. Thanks a lot!
@changelog_1122_li
@changelog_1140_li
TRUNC was added as an alias for TRUNCATE.
TRUNC was added as an alias for TRUNCATE.
@changelog_1123_li
@changelog_1141_li
Small optimisation for accessing result values by column name.
Small optimisation for accessing result values by column name.
@changelog_1124_li
@changelog_1142_li
Fix for bug in Statement.getMoreResults(int)
Fix for bug in Statement.getMoreResults(int)
@changelog_1125_li
@changelog_1143_li
The SCRIPT statements now supports filtering by schema and table. Thanks a lot to Jacob Qvortrup for providing the patch!
The SCRIPT statements now supports filtering by schema and table. Thanks a lot to Jacob Qvortrup for providing the patch!
@changelog_1126_h2
@changelog_1144_h2
Version 1.3.166 (2012-04-08)
Version 1.3.166 (2012-04-08)
@changelog_1127_li
@changelog_1145_li
Indexes on column that are larger than half the page size (wide indexes) could sometimes get corrupt, resulting in an ArrayIndexOutOfBoundsException in PageBtree.getRow or "Row not found" in PageBtreeLeaf. Also, such indexes used too much disk space.
Indexes on column that are larger than half the page size (wide indexes) could sometimes get corrupt, resulting in an ArrayIndexOutOfBoundsException in PageBtree.getRow or "Row not found" in PageBtreeLeaf. Also, such indexes used too much disk space.
@changelog_1128_li
@changelog_1146_li
Server mode: when retrieving more than 64 rows each containing a CLOB or BLOB, the error message "The object is already closed" was thrown.
Server mode: when retrieving more than 64 rows each containing a CLOB or BLOB, the error message "The object is already closed" was thrown.
@changelog_1129_li
@changelog_1147_li
ConvertTraceFile: the time in the trace file is now parsed as a long.
ConvertTraceFile: the time in the trace file is now parsed as a long.
@changelog_1130_li
@changelog_1148_li
Invalid connection settings are now detected.
Invalid connection settings are now detected.
@changelog_1131_li
@changelog_1149_li
Issue 387: WHERE condition getting pushed into sub-query with LIMIT.
Issue 387: WHERE condition getting pushed into sub-query with LIMIT.
@changelog_1132_h2
@changelog_1150_h2
Version 1.3.165 (2012-03-18)
Version 1.3.165 (2012-03-18)
@changelog_1133_li
@changelog_1151_li
Better string representation for decimal values (for example 0.00000000 instead of 0E-26).
Better string representation for decimal values (for example 0.00000000 instead of 0E-26).
@changelog_1134_li
@changelog_1152_li
Prepared statements could only be re-used if the same data types were used the second time they were executed.
Prepared statements could only be re-used if the same data types were used the second time they were executed.
@changelog_1135_li
@changelog_1153_li
In error messages about referential constraint violation, the values are now included.
In error messages about referential constraint violation, the values are now included.
@changelog_1136_li
@changelog_1154_li
SCRIPT and RUNSCRIPT: the password can now be set using a prepared statement. Previously, it was required to be a literal in the SQL statement.
SCRIPT and RUNSCRIPT: the password can now be set using a prepared statement. Previously, it was required to be a literal in the SQL statement.
@changelog_1137_li
@changelog_1155_li
MySQL compatibility: SUBSTR with a negative start index now works like MySQL.
MySQL compatibility: SUBSTR with a negative start index now works like MySQL.
@changelog_1138_li
@changelog_1156_li
When enabling autocommit, the transaction is now committed (as required by the JDBC API).
When enabling autocommit, the transaction is now committed (as required by the JDBC API).
@changelog_1139_li
@changelog_1157_li
The shell script <code>h2.sh</code> did not work with spaces in the path. It also works now with quoted spaces in the argument list. Thanks a lot to Shimizu Fumiyuki for the patch!
The shell script <code>h2.sh</code> did not work with spaces in the path. It also works now with quoted spaces in the argument list. Thanks a lot to Shimizu Fumiyuki for the patch!
@changelog_1140_li
@changelog_1158_li
If the transaction log could not be truncated because of an uncommitted transaction, now "Transaction log could not be truncated" is written to the .trace.db file. Before, the database file was growing and it was hard to find out what the root cause was. To avoid the database file from growing, a new feature to automatically rollback the oldest transaction is available now. To enable it, append ;LOG_SIZE_LIMIT=32 to the database URL (in that case, the oldest session is rolled back if the transaction log is 32 MB).
If the transaction log could not be truncated because of an uncommitted transaction, now "Transaction log could not be truncated" is written to the .trace.db file. Before, the database file was growing and it was hard to find out what the root cause was. To avoid the database file from growing, a new feature to automatically rollback the oldest transaction is available now. To enable it, append ;LOG_SIZE_LIMIT=32 to the database URL (in that case, the oldest session is rolled back if the transaction log is 32 MB).
@changelog_1141_li
@changelog_1159_li
ALTER TABLE ADD can now add more than one column at a time.
ALTER TABLE ADD can now add more than one column at a time.
@changelog_1142_li
@changelog_1160_li
Issue 380: ALTER TABLE ADD FOREIGN KEY with an explicit index didn't verify the index can be used, which would lead to a NullPointerException later on.
Issue 380: ALTER TABLE ADD FOREIGN KEY with an explicit index didn't verify the index can be used, which would lead to a NullPointerException later on.
@changelog_1143_li
@changelog_1161_li
Issue 384: the wrong kind of exception (NullPointerException) was thrown in a UNION query with an incorrect ORDER BY expression.
Issue 384: the wrong kind of exception (NullPointerException) was thrown in a UNION query with an incorrect ORDER BY expression.
@changelog_1144_li
@changelog_1162_li
Issue 362: support LIMIT in UPDATE statements.
Issue 362: support LIMIT in UPDATE statements.
@changelog_1145_li
@changelog_1163_li
Browser: if no default browser is set, Google Chrome is now used if available. If not available, then Konqueror, Netscape, or Opera is used if available (as before).
Browser: if no default browser is set, Google Chrome is now used if available. If not available, then Konqueror, Netscape, or Opera is used if available (as before).
@changelog_1146_li
@changelog_1164_li
CSV tool: new feature to disable writing the column header (option writeColumnHeader).
CSV tool: new feature to disable writing the column header (option writeColumnHeader).
@changelog_1147_li
@changelog_1165_li
CSV tool: new feature to preserve the case sensitivity of column names (option caseSensitiveColumnNames).
CSV tool: new feature to preserve the case sensitivity of column names (option caseSensitiveColumnNames).
@changelog_1148_li
@changelog_1166_li
PostgreSQL compatibility: LOG(x) is base 10 in the PostgreSQL mode.
PostgreSQL compatibility: LOG(x) is base 10 in the PostgreSQL mode.
@changelog_1149_h2
@changelog_1167_h2
Version 1.3.164 (2012-02-03)
Version 1.3.164 (2012-02-03)
@changelog_1150_li
@changelog_1168_li
New built-in function ARRAY_CONTAINS.
New built-in function ARRAY_CONTAINS.
@changelog_1151_li
@changelog_1169_li
Some DatabaseMetaData methods didn't work when using ALLOW_LITERALS NONE.
Some DatabaseMetaData methods didn't work when using ALLOW_LITERALS NONE.
@changelog_1152_li
@changelog_1170_li
Trying to convert a VARCHAR to UUID will now fail if the text contains a character that is not a hex digit, '-', or not a whitespace.
Trying to convert a VARCHAR to UUID will now fail if the text contains a character that is not a hex digit, '-', or not a whitespace.
@changelog_1153_li
@changelog_1171_li
TriggerAdapter: in "before" triggers, values can be changed using the ResultSet.updateX methods.
TriggerAdapter: in "before" triggers, values can be changed using the ResultSet.updateX methods.
@changelog_1154_li
@changelog_1172_li
Creating a table with column data type NULL now works (even if not very useful).
Creating a table with column data type NULL now works (even if not very useful).
@changelog_1155_li
@changelog_1173_li
ALTER TABLE ALTER COLUMN no longer copies the data for widening conversions (for example if only the precision was increased) unless necessary.
ALTER TABLE ALTER COLUMN no longer copies the data for widening conversions (for example if only the precision was increased) unless necessary.
@changelog_1156_li
@changelog_1174_li
Multi-threaded kernel: concurrently running an online backup and updating the database resulted in a broken (transactionally incorrect) backup file in some cases.
Multi-threaded kernel: concurrently running an online backup and updating the database resulted in a broken (transactionally incorrect) backup file in some cases.
@changelog_1157_li
@changelog_1175_li
The script created by SCRIPT DROP did not always work if multiple views existed that depend on each other.
The script created by SCRIPT DROP did not always work if multiple views existed that depend on each other.
@changelog_1158_li
@changelog_1176_li
MathUtils.getSecureRandom could log a warning to System.err in case the /dev/random is very slow, and the System.getProperties().toString() returned a string larger than 64 KB.
MathUtils.getSecureRandom could log a warning to System.err in case the /dev/random is very slow, and the System.getProperties().toString() returned a string larger than 64 KB.
@changelog_1159_li
@changelog_1177_li
The database file locking mechanism "FS" (;FILE_LOCK=FS) did not work on Linux since version 1.3.161.
The database file locking mechanism "FS" (;FILE_LOCK=FS) did not work on Linux since version 1.3.161.
@changelog_1160_li
@changelog_1178_li
Sequences: the functions NEXTVAL and CURRVAL did not work as expected when using quoted, mixed case sequence names.
Sequences: the functions NEXTVAL and CURRVAL did not work as expected when using quoted, mixed case sequence names.
@changelog_1161_li
@changelog_1179_li
The constructor for Csv objects is now public, and Csv.getInstance() is now deprecated.
The constructor for Csv objects is now public, and Csv.getInstance() is now deprecated.
@changelog_1162_li
@changelog_1180_li
SimpleResultSet: updating a result set is now supported.
SimpleResultSet: updating a result set is now supported.
@changelog_1163_li
@changelog_1181_li
Database URL: extra semicolons are not supported.
Database URL: extra semicolons are not supported.
@changelog_1164_h2
@changelog_1182_h2
Version 1.3.163 (2011-12-30)
Version 1.3.163 (2011-12-30)
@changelog_1165_li
@changelog_1183_li
On out of disk space, the database could get corrupt sometimes, if later write operations succeeded. The same problem happened on other kinds of I/O exceptions (where one or some of the writes fail, but subsequent writes succeed). Now the file is closed on the first unsuccessful write operation, so that later requests fail consistently.
On out of disk space, the database could get corrupt sometimes, if later write operations succeeded. The same problem happened on other kinds of I/O exceptions (where one or some of the writes fail, but subsequent writes succeed). Now the file is closed on the first unsuccessful write operation, so that later requests fail consistently.
@changelog_1166_li
@changelog_1184_li
DatabaseEventListener.diskSpaceIsLow() is no longer supported because it can't be guaranteed that it always works correctly.
DatabaseEventListener.diskSpaceIsLow() is no longer supported because it can't be guaranteed that it always works correctly.
@changelog_1167_li
@changelog_1185_li
XMLTEXT now supports an optional parameter to escape newlines.
XMLTEXT now supports an optional parameter to escape newlines.
@changelog_1168_li
@changelog_1186_li
XMLNODE now support an optional parameter to disable indentation.
XMLNODE now support an optional parameter to disable indentation.
@changelog_1169_li
@changelog_1187_li
Csv.write now formats date, time, and timestamp values using java.sql.Date / Time / Timestamp.toString(). Previously, ResultSet.getString() was used, which didn't work well for Oracle.
Csv.write now formats date, time, and timestamp values using java.sql.Date / Time / Timestamp.toString(). Previously, ResultSet.getString() was used, which didn't work well for Oracle.
@changelog_1170_li
@changelog_1188_li
The shell script <code>h2.sh</code> can now be run from within a different directory. Thanks a lot to Daniel Serodio for the patch!
The shell script <code>h2.sh</code> can now be run from within a different directory. Thanks a lot to Daniel Serodio for the patch!
@changelog_1171_li
@changelog_1189_li
The page size of a persistent database can now be queries using: select * from information_schema.settings where name = 'info.PAGE_SIZE'
The page size of a persistent database can now be queries using: select * from information_schema.settings where name = 'info.PAGE_SIZE'
@changelog_1172_li
@changelog_1190_li
In the server mode, BLOB and CLOB objects are no longer closed when the result set is closed (as required by the JDBC spec).
In the server mode, BLOB and CLOB objects are no longer closed when the result set is closed (as required by the JDBC spec).
@cheatSheet_1000_h1
@cheatSheet_1000_h1
...
@@ -4438,43 +4492,49 @@ Pluggable or User-Defined Tables
...
@@ -4438,43 +4492,49 @@ Pluggable or User-Defined Tables
@features_1595_p
@features_1595_p
and then create the table from SQL like this:
and then create the table from SQL like this:
@features_1596_h2
@features_1596_p
Triggers
It is also possible to pass in parameters to the table engine, like so:
@features_1597_p
@features_1597_p
In which case the parameters are passed down in the tableEngineParams field of the CreateTableData object.
@features_1598_h2
Triggers
@features_1599_p
This database supports Java triggers that are called before or after a row is updated, inserted or deleted. Triggers can be used for complex consistency checks, or to update related data in the database. It is also possible to use triggers to simulate materialized views. For a complete sample application, see <code>src/test/org/h2/samples/TriggerSample.java</code>. A Java trigger must implement the interface <code>org.h2.api.Trigger</code>. The trigger class must be available in the classpath of the database engine (when using the server mode, it must be in the classpath of the server).
This database supports Java triggers that are called before or after a row is updated, inserted or deleted. Triggers can be used for complex consistency checks, or to update related data in the database. It is also possible to use triggers to simulate materialized views. For a complete sample application, see <code>src/test/org/h2/samples/TriggerSample.java</code>. A Java trigger must implement the interface <code>org.h2.api.Trigger</code>. The trigger class must be available in the classpath of the database engine (when using the server mode, it must be in the classpath of the server).
@features_1598_p
@features_1600_p
The connection can be used to query or update data in other tables. The trigger then needs to be defined in the database:
The connection can be used to query or update data in other tables. The trigger then needs to be defined in the database:
@features_1599_p
@features_1601_p
The trigger can be used to veto a change by throwing a <code>SQLException</code>.
The trigger can be used to veto a change by throwing a <code>SQLException</code>.
@features_1600_p
@features_1602_p
As an alternative to implementing the <code>Trigger</code> interface, an application can extend the abstract class <code>org.h2.tools.TriggerAdapter</code>. This will allows to use the <code>ResultSet</code> interface within trigger implementations. In this case, only the <code>fire</code> method needs to be implemented:
As an alternative to implementing the <code>Trigger</code> interface, an application can extend the abstract class <code>org.h2.tools.TriggerAdapter</code>. This will allows to use the <code>ResultSet</code> interface within trigger implementations. In this case, only the <code>fire</code> method needs to be implemented:
@features_1601_h2
@features_1603_h2
Compacting a Database
Compacting a Database
@features_1602_p
@features_1604_p
Empty space in the database file re-used automatically. When closing the database, the database is automatically compacted for up to 200 milliseconds by default. To compact more, use the SQL statement SHUTDOWN COMPACT. However re-creating the database may further reduce the database size because this will re-build the indexes. Here is a sample function to do this:
Empty space in the database file re-used automatically. When closing the database, the database is automatically compacted for up to 200 milliseconds by default. To compact more, use the SQL statement SHUTDOWN COMPACT. However re-creating the database may further reduce the database size because this will re-build the indexes. Here is a sample function to do this:
@features_1603_p
@features_1605_p
See also the sample application <code>org.h2.samples.Compact</code>. The commands <code>SCRIPT / RUNSCRIPT</code> can be used as well to create a backup of a database and re-build the database from the script.
See also the sample application <code>org.h2.samples.Compact</code>. The commands <code>SCRIPT / RUNSCRIPT</code> can be used as well to create a backup of a database and re-build the database from the script.
@features_1604_h2
@features_1606_h2
Cache Settings
Cache Settings
@features_1605_p
@features_1607_p
The database keeps most frequently used data in the main memory. The amount of memory used for caching can be changed using the setting <code>CACHE_SIZE</code>. This setting can be set in the database connection URL (<code>jdbc:h2:~/test;CACHE_SIZE=131072</code>), or it can be changed at runtime using <code>SET CACHE_SIZE size</code>. The size of the cache, as represented by <code>CACHE_SIZE</code> is measured in KB, with each KB being 1024 bytes. This setting has no effect for in-memory databases. For persistent databases, the setting is stored in the database and re-used when the database is opened the next time. However, when opening an existing database, the cache size is set to at most half the amount of memory available for the virtual machine (Runtime.getRuntime().maxMemory()), even if the cache size setting stored in the database is larger; however the setting stored in the database is kept. Setting the cache size in the database URL or explicitly using <code>SET CACHE_SIZE</code> overrides this value (even if larger than the physical memory). To get the current used maximum cache size, use the query <code>SELECT * FROM INFORMATION_SCHEMA.SETTINGS WHERE NAME = 'info.CACHE_MAX_SIZE'</code>
The database keeps most frequently used data in the main memory. The amount of memory used for caching can be changed using the setting <code>CACHE_SIZE</code>. This setting can be set in the database connection URL (<code>jdbc:h2:~/test;CACHE_SIZE=131072</code>), or it can be changed at runtime using <code>SET CACHE_SIZE size</code>. The size of the cache, as represented by <code>CACHE_SIZE</code> is measured in KB, with each KB being 1024 bytes. This setting has no effect for in-memory databases. For persistent databases, the setting is stored in the database and re-used when the database is opened the next time. However, when opening an existing database, the cache size is set to at most half the amount of memory available for the virtual machine (Runtime.getRuntime().maxMemory()), even if the cache size setting stored in the database is larger; however the setting stored in the database is kept. Setting the cache size in the database URL or explicitly using <code>SET CACHE_SIZE</code> overrides this value (even if larger than the physical memory). To get the current used maximum cache size, use the query <code>SELECT * FROM INFORMATION_SCHEMA.SETTINGS WHERE NAME = 'info.CACHE_MAX_SIZE'</code>
@features_1606_p
@features_1608_p
An experimental scan-resistant cache algorithm "Two Queue" (2Q) is available. To enable it, append <code>;CACHE_TYPE=TQ</code> to the database URL. The cache might not actually improve performance. If you plan to use it, please run your own test cases first.
An experimental scan-resistant cache algorithm "Two Queue" (2Q) is available. To enable it, append <code>;CACHE_TYPE=TQ</code> to the database URL. The cache might not actually improve performance. If you plan to use it, please run your own test cases first.
@features_1607_p
@features_1609_p
Also included is an experimental second level soft reference cache. Rows in this cache are only garbage collected on low memory. By default the second level cache is disabled. To enable it, use the prefix <code>SOFT_</code>. Example: <code>jdbc:h2:~/test;CACHE_TYPE=SOFT_LRU</code>. The cache might not actually improve performance. If you plan to use it, please run your own test cases first.
Also included is an experimental second level soft reference cache. Rows in this cache are only garbage collected on low memory. By default the second level cache is disabled. To enable it, use the prefix <code>SOFT_</code>. Example: <code>jdbc:h2:~/test;CACHE_TYPE=SOFT_LRU</code>. The cache might not actually improve performance. If you plan to use it, please run your own test cases first.
@features_1608_p
@features_1610_p
To get information about page reads and writes, and the current caching algorithm in use, call <code>SELECT * FROM INFORMATION_SCHEMA.SETTINGS</code>. The number of pages read / written is listed.
To get information about page reads and writes, and the current caching algorithm in use, call <code>SELECT * FROM INFORMATION_SCHEMA.SETTINGS</code>. The number of pages read / written is listed.
Similar Projects and Differences to Other Storage Engines
- <a href="#tableEngine">Table Engine for H2</a>
@mvstore_1020_a
@mvstore_1020_a
Current State
Similar Projects and Differences to Other Storage Engines
@mvstore_1021_a
@mvstore_1021_a
Current State
@mvstore_1022_a
Requirements
Requirements
@mvstore_1022_h2
@mvstore_1023_h2
Overview
Overview
@mvstore_1023_p
@mvstore_1024_p
The MVStore is work in progress, and is planned to be the next storage subsystem of H2. But it can be also directly within an application, without using JDBC or SQL.
The MVStore is work in progress, and is planned to be the next storage subsystem of H2. But it can be also directly within an application, without using JDBC or SQL.
@mvstore_1024_li
@mvstore_1025_li
MVStore stands for "multi-version store".
MVStore stands for "multi-version store".
@mvstore_1025_li
@mvstore_1026_li
Each store contains a number of maps (using the <code>java.util.Map</code> interface).
Each store contains a number of maps (using the <code>java.util.Map</code> interface).
@mvstore_1026_li
@mvstore_1027_li
Both file-based persistence and in-memory operation are supported.
Both file-based persistence and in-memory operation are supported.
@mvstore_1027_li
@mvstore_1028_li
It is intended to be fast, simple to use, and small.
It is intended to be fast, simple to use, and small.
@mvstore_1028_li
@mvstore_1029_li
Old versions of the data can be read concurrently with all other operations.
Old versions of the data can be read concurrently with all other operations.
@mvstore_1029_li
@mvstore_1030_li
Transaction are supported (including concurrent transactions and 2-phase commit).
Transaction are supported (including concurrent transactions and 2-phase commit).
@mvstore_1030_li
@mvstore_1031_li
The tool is very modular. It supports pluggable data types / serialization, pluggable map implementations (B-tree, R-tree, concurrent B-tree currently), BLOB storage, and a file system abstraction to support encrypted files and zip files.
The tool is very modular. It supports pluggable data types / serialization, pluggable map implementations (B-tree, R-tree, concurrent B-tree currently), BLOB storage, and a file system abstraction to support encrypted files and zip files.
@mvstore_1031_h2
@mvstore_1032_h2
Example Code
Example Code
@mvstore_1032_p
@mvstore_1033_p
The following sample code show how to create a store, open a map, add some data, and access the current and an old version:
The following sample code show how to create a store, open a map, add some data, and access the current and an old version:
@mvstore_1033_h2
@mvstore_1034_h2
Store Builder
Store Builder
@mvstore_1034_p
@mvstore_1035_p
The <code>MVStore.Builder</code> provides a fluid interface to build a store if more complex configuration options are used. The following code contains all supported configuration options:
The <code>MVStore.Builder</code> provides a fluid interface to build a store if more complex configuration options are used. The following code contains all supported configuration options:
@mvstore_1035_li
@mvstore_1036_li
cacheSizeMB: the cache size in MB.
cacheSizeMB: the cache size in MB.
@mvstore_1036_li
@mvstore_1037_li
compressData: compress the data when storing.
compressData: compress the data when storing.
@mvstore_1037_li
@mvstore_1038_li
encryptionKey: the encryption key for file encryption.
encryptionKey: the encryption key for file encryption.
@mvstore_1038_li
@mvstore_1039_li
fileName: the name of the file, for file based stores.
fileName: the name of the file, for file based stores.
@mvstore_1039_li
@mvstore_1040_li
readOnly: open the file in read-only mode.
readOnly: open the file in read-only mode.
@mvstore_1040_li
@mvstore_1041_li
writeBufferSize: the size of the write buffer in MB.
writeBufferSize: the size of the write buffer in MB.
@mvstore_1041_li
@mvstore_1042_li
writeDelay: the maximum delay until committed changes are stored (unless stored explicitly).
writeDelay: the maximum delay until committed changes are stored (unless stored explicitly).
@mvstore_1042_h2
@mvstore_1043_h2
R-Tree
R-Tree
@mvstore_1043_p
@mvstore_1044_p
The <code>MVRTreeMap</code> is an R-tree implementation that supports fast spatial queries. It can be used as follows:
The <code>MVRTreeMap</code> is an R-tree implementation that supports fast spatial queries. It can be used as follows:
@mvstore_1044_p
@mvstore_1045_p
The default number of dimensions is 2. To use a different number of dimensions, call <code>new MVRTreeMap.Builder<String>().dimensions(3)</code>. The minimum number of dimensions is 1, the maximum is 255.
The default number of dimensions is 2. To use a different number of dimensions, call <code>new MVRTreeMap.Builder<String>().dimensions(3)</code>. The minimum number of dimensions is 1, the maximum is 255.
@mvstore_1045_h2
@mvstore_1046_h2
Features
Features
@mvstore_1046_h3
@mvstore_1047_h3
Maps
Maps
@mvstore_1047_p
@mvstore_1048_p
Each store supports a set of named maps. A map is sorted by key, and supports the common lookup operations, including access to the first and last key, iterate over some or all keys, and so on.
Each store supports a set of named maps. A map is sorted by key, and supports the common lookup operations, including access to the first and last key, iterate over some or all keys, and so on.
@mvstore_1048_p
@mvstore_1049_p
Also supported, and very uncommon for maps, is fast index lookup: the keys of the map can be accessed like a list (get the key at the given index, get the index of a certain key). That means getting the median of two keys is trivial, and range of keys can be counted very quickly. The iterator supports fast skipping. This is possible because internally, each map is organized in the form of a counted B+-tree.
Also supported, and very uncommon for maps, is fast index lookup: the keys of the map can be accessed like a list (get the key at the given index, get the index of a certain key). That means getting the median of two keys is trivial, and range of keys can be counted very quickly. The iterator supports fast skipping. This is possible because internally, each map is organized in the form of a counted B+-tree.
@mvstore_1049_p
@mvstore_1050_p
In database terms, a map can be used like a table, where the key of the map is the primary key of the table, and the value is the row. A map can also represent an index, where the key of the map is the key of the index, and the value of the map is the primary key of the table (for non-unique indexes, the key of the map must also contain the primary key).
In database terms, a map can be used like a table, where the key of the map is the primary key of the table, and the value is the row. A map can also represent an index, where the key of the map is the key of the index, and the value of the map is the primary key of the table (for non-unique indexes, the key of the map must also contain the primary key).
@mvstore_1050_h3
@mvstore_1051_h3
Versions
Versions
@mvstore_1051_p
@mvstore_1052_p
Multiple versions are supported. A version is a snapshot of all the data of all maps at a given point in time. A transaction is a number of actions between two versions.
Multiple versions are supported. A version is a snapshot of all the data of all maps at a given point in time. A transaction is a number of actions between two versions.
@mvstore_1052_p
@mvstore_1053_p
Versions are not immediately persisted; instead, only the version counter is incremented. If there is a change after switching to a new version, a snapshot of the old version is kept in memory, so that it can still be read.
Versions are not immediately persisted; instead, only the version counter is incremented. If there is a change after switching to a new version, a snapshot of the old version is kept in memory, so that it can still be read.
@mvstore_1053_p
@mvstore_1054_p
Old persisted versions are readable until the old data was explicitly overwritten. Creating a snapshot is fast: only the pages that are changed after a snapshot are copied. This behavior is also called COW (copy on write).
Old persisted versions are readable until the old data was explicitly overwritten. Creating a snapshot is fast: only the pages that are changed after a snapshot are copied. This behavior is also called COW (copy on write).
@mvstore_1054_p
@mvstore_1055_p
Rollback is supported (rollback to any old in-memory version or an old persisted version).
Rollback is supported (rollback to any old in-memory version or an old persisted version).
@mvstore_1055_h3
@mvstore_1056_h3
Transactions
Transactions
@mvstore_1056_p
@mvstore_1057_p
The multi-version support is the basis for the transaction support. In the simple case, when only one transaction is open at a time, rolling back the transaction only requires to revert to an old version.
The multi-version support is the basis for the transaction support. In the simple case, when only one transaction is open at a time, rolling back the transaction only requires to revert to an old version.
@mvstore_1057_p
@mvstore_1058_p
To support multiple concurrent open transactions, a transaction utility is included, the <code>TransactionStore</code>. This utility stores the changed entries in a separate map, similar to a transaction log (except that only the key of a changed row is stored, and the entries of a transaction are removed when the transaction is committed). The storage overhead of this utility is very small compared to the overhead of a regular transaction log. The tool supports PostgreSQL style "read committed" transaction isolation. There is no limit on the size of a transaction (the log is not kept in memory). The tool supports savepoints, two-phase commit, and other features typically available in a database.
To support multiple concurrent open transactions, a transaction utility is included, the <code>TransactionStore</code>. This utility stores the changed entries in a separate map, similar to a transaction log (except that only the key of a changed row is stored, and the entries of a transaction are removed when the transaction is committed). The storage overhead of this utility is very small compared to the overhead of a regular transaction log. The tool supports PostgreSQL style "read committed" transaction isolation. There is no limit on the size of a transaction (the log is not kept in memory). The tool supports savepoints, two-phase commit, and other features typically available in a database.
@mvstore_1058_h3
@mvstore_1059_h3
In-Memory Performance and Usage
In-Memory Performance and Usage
@mvstore_1059_p
@mvstore_1060_p
Performance of in-memory operations is comparable with <code>java.util.TreeMap</code> (many operations are actually faster), but usually slower than <code>java.util.HashMap</code>.
Performance of in-memory operations is comparable with <code>java.util.TreeMap</code> (many operations are actually faster), but usually slower than <code>java.util.HashMap</code>.
@mvstore_1060_p
@mvstore_1061_p
The memory overhead for large maps is slightly better than for the regular map implementations, but there is a higher overhead per map. For maps with less than 25 entries, the regular map implementations use less memory on average.
The memory overhead for large maps is slightly better than for the regular map implementations, but there is a higher overhead per map. For maps with less than 25 entries, the regular map implementations use less memory on average.
@mvstore_1061_p
@mvstore_1062_p
If no file name is specified, the store operates purely in memory. Except for persisting data, all features are supported in this mode (multi-versioning, index lookup, R-tree and so on). If a file name is specified, all operations occur in memory (with the same performance characteristics) until data is persisted.
If no file name is specified, the store operates purely in memory. Except for persisting data, all features are supported in this mode (multi-versioning, index lookup, R-tree and so on). If a file name is specified, all operations occur in memory (with the same performance characteristics) until data is persisted.
@mvstore_1062_h3
@mvstore_1063_h3
Pluggable Data Types
Pluggable Data Types
@mvstore_1063_p
@mvstore_1064_p
Serialization is pluggable. The default serialization currently supports many common data types, and uses Java serialization for other objects. The following classes are currently directly supported: <code>Boolean, Byte, Short, Character, Integer, Long, Float, Double, BigInteger, BigDecimal, String, UUID, Date</code> and arrays (both primitive arrays and object arrays).
Serialization is pluggable. The default serialization currently supports many common data types, and uses Java serialization for other objects. The following classes are currently directly supported: <code>Boolean, Byte, Short, Character, Integer, Long, Float, Double, BigInteger, BigDecimal, String, UUID, Date</code> and arrays (both primitive arrays and object arrays).
@mvstore_1064_p
@mvstore_1065_p
Parameterized data types are supported (for example one could build a string data type that limits the length for some reason).
Parameterized data types are supported (for example one could build a string data type that limits the length for some reason).
@mvstore_1065_p
@mvstore_1066_p
The storage engine itself does not have any length limits, so that keys, values, pages, and chunks can be very big (as big as fits in memory). Also, there is no inherent limit to the number of maps and chunks. Due to using a log structured storage, there is no special case handling for large keys or pages.
The storage engine itself does not have any length limits, so that keys, values, pages, and chunks can be very big (as big as fits in memory). Also, there is no inherent limit to the number of maps and chunks. Due to using a log structured storage, there is no special case handling for large keys or pages.
@mvstore_1066_h3
@mvstore_1067_h3
BLOB Support
BLOB Support
@mvstore_1067_p
@mvstore_1068_p
There is a mechanism that stores large binary objects by splitting them into smaller blocks. This allows to store objects that don't fit in memory. Streaming as well as random access reads on such objects are supported. This tool is written on top of the store (only using the map interface).
There is a mechanism that stores large binary objects by splitting them into smaller blocks. This allows to store objects that don't fit in memory. Streaming as well as random access reads on such objects are supported. This tool is written on top of the store (only using the map interface).
@mvstore_1068_h3
@mvstore_1069_h3
R-Tree and Pluggable Map Implementations
R-Tree and Pluggable Map Implementations
@mvstore_1069_p
@mvstore_1070_p
The map implementation is pluggable. In addition to the default <code>MVMap</code> (multi-version map), there is a multi-version R-tree map implementation for spatial operations (contain and intersection; nearest neighbor is not yet implemented).
The map implementation is pluggable. In addition to the default <code>MVMap</code> (multi-version map), there is a multi-version R-tree map implementation for spatial operations (contain and intersection; nearest neighbor is not yet implemented).
@mvstore_1070_h3
@mvstore_1071_h3
Concurrent Operations and Caching
Concurrent Operations and Caching
@mvstore_1071_p
@mvstore_1072_p
The default map implementation supports concurrent reads on old versions of the data. All such read operations can occur in parallel. Concurrent reads from the page cache, as well as concurrent reads from the file system are supported.
The default map implementation supports concurrent reads on old versions of the data. All such read operations can occur in parallel. Concurrent reads from the page cache, as well as concurrent reads from the file system are supported.
@mvstore_1072_p
@mvstore_1073_p
Storing changes can occur concurrently to modifying the data, as it operates on a snapshot.
Storing changes can occur concurrently to modifying the data, as it operates on a snapshot.
@mvstore_1073_p
@mvstore_1074_p
Caching is done on the page level. The page cache is a concurrent LIRS cache, which should be resistant against scan operations.
Caching is done on the page level. The page cache is a concurrent LIRS cache, which should be resistant against scan operations.
@mvstore_1074_p
@mvstore_1075_p
The default map implementation does not support concurrent modification operations on a map (the same as <code>HashMap</code> and <code>TreeMap</code>). Similar to those classes, the map tries to detect concurrent modification.
The default map implementation does not support concurrent modification operations on a map (the same as <code>HashMap</code> and <code>TreeMap</code>). Similar to those classes, the map tries to detect concurrent modification.
@mvstore_1075_p
@mvstore_1076_p
With the <code>MVMapConcurrent</code> implementation, read operations even on the newest version can happen concurrently with all other operations, without risk of corruption. This comes with slightly reduced speed in single threaded mode, the same as with other <code>ConcurrentHashMap</code> implementations. Write operations first read the relevant area from disk to memory (this can happen concurrently), and only then modify the data. The in-memory part of write operations is synchronized.
With the <code>MVMapConcurrent</code> implementation, read operations even on the newest version can happen concurrently with all other operations, without risk of corruption. This comes with slightly reduced speed in single threaded mode, the same as with other <code>ConcurrentHashMap</code> implementations. Write operations first read the relevant area from disk to memory (this can happen concurrently), and only then modify the data. The in-memory part of write operations is synchronized.
@mvstore_1076_p
@mvstore_1077_p
For fully scalable concurrent write operations to a map (in-memory and to disk), the map could be split into multiple maps in different stores ('sharding'). The plan is to add such a mechanism later when needed.
For fully scalable concurrent write operations to a map (in-memory and to disk), the map could be split into multiple maps in different stores ('sharding'). The plan is to add such a mechanism later when needed.
@mvstore_1077_h3
@mvstore_1078_h3
Log Structured Storage
Log Structured Storage
@mvstore_1078_p
@mvstore_1079_p
Changes are buffered in memory, and once enough changes have accumulated, they are written in one continuous disk write operation. (According to a test, write throughput of a common SSD gets higher the larger the block size, until a block size of 2 MB, and then does not further increase.) By default, committed changes are automatically written once every second in a background thread, even if only little data was changed. Changes can also be written explicitly by calling <code>store()</code>. To avoid out of memory, uncommitted changes are also written when needed, however they are rolled back when closing the store, or at the latest (when the store was not correctly closed) when opening the store.
Changes are buffered in memory, and once enough changes have accumulated, they are written in one continuous disk write operation. (According to a test, write throughput of a common SSD gets higher the larger the block size, until a block size of 2 MB, and then does not further increase.) By default, committed changes are automatically written once every second in a background thread, even if only little data was changed. Changes can also be written explicitly by calling <code>store()</code>. To avoid out of memory, uncommitted changes are also written when needed, however they are rolled back when closing the store, or at the latest (when the store was not correctly closed) when opening the store.
@mvstore_1079_p
@mvstore_1080_p
When storing, all changed pages are serialized, optionally compressed using the LZF algorithm, and written sequentially to a free area of the file. Each such change set is called a chunk. All parent pages of the changed B-trees are stored in this chunk as well, so that each chunk also contains the root of each changed map (which is the entry point to read this version of the data). There is no separate index: all data is stored as a list of pages. Per store, there is one additional map that contains the metadata (the list of maps, where the root page of each map is stored, and the list of chunks).
When storing, all changed pages are serialized, optionally compressed using the LZF algorithm, and written sequentially to a free area of the file. Each such change set is called a chunk. All parent pages of the changed B-trees are stored in this chunk as well, so that each chunk also contains the root of each changed map (which is the entry point to read this version of the data). There is no separate index: all data is stored as a list of pages. Per store, there is one additional map that contains the metadata (the list of maps, where the root page of each map is stored, and the list of chunks).
@mvstore_1080_p
@mvstore_1081_p
There are usually two write operations per chunk: one to store the chunk data (the pages), and one to update the file header (so it points to the latest chunk). If the chunk is appended at the end of the file, the file header is only written at the end of the chunk.
There are usually two write operations per chunk: one to store the chunk data (the pages), and one to update the file header (so it points to the latest chunk). If the chunk is appended at the end of the file, the file header is only written at the end of the chunk.
@mvstore_1081_p
@mvstore_1082_p
There is no transaction log, no undo log, and there are no in-place updates (however unused chunks are overwritten by default).
There is no transaction log, no undo log, and there are no in-place updates (however unused chunks are overwritten by default).
@mvstore_1082_p
@mvstore_1083_p
Old data is kept for at least 45 seconds (configurable), so that there are no explicit sync operations required to guarantee data consistency, but an application can also sync explicitly when needed. To reuse disk space, the chunks with the lowest amount of live data are compacted (the live data is simply stored again in the next chunk). To improve data locality and disk space usage, the plan is to automatically defragment and compact data.
Old data is kept for at least 45 seconds (configurable), so that there are no explicit sync operations required to guarantee data consistency, but an application can also sync explicitly when needed. To reuse disk space, the chunks with the lowest amount of live data are compacted (the live data is simply stored again in the next chunk). To improve data locality and disk space usage, the plan is to automatically defragment and compact data.
@mvstore_1083_p
@mvstore_1084_p
Compared to traditional storage engines (that use a transaction log, undo log, and main storage area), the log structured storage is simpler, more flexible, and typically needs less disk operations per change, as data is only written once instead of twice or 3 times, and because the B-tree pages are always full (they are stored next to each other) and can be easily compressed. But temporarily, disk space usage might actually be a bit higher than for a regular database, as disk space is not immediately re-used (there are no in-place updates).
Compared to traditional storage engines (that use a transaction log, undo log, and main storage area), the log structured storage is simpler, more flexible, and typically needs less disk operations per change, as data is only written once instead of twice or 3 times, and because the B-tree pages are always full (they are stored next to each other) and can be easily compressed. But temporarily, disk space usage might actually be a bit higher than for a regular database, as disk space is not immediately re-used (there are no in-place updates).
@mvstore_1084_h3
@mvstore_1085_h3
File System Abstraction, File Locking and Online Backup
File System Abstraction, File Locking and Online Backup
@mvstore_1085_p
@mvstore_1086_p
The file system is pluggable (the same file system abstraction is used as H2 uses). The file can be encrypted using an encrypting file system. Other file system implementations support reading from a compressed zip or jar file.
The file system is pluggable (the same file system abstraction is used as H2 uses). The file can be encrypted using an encrypting file system. Other file system implementations support reading from a compressed zip or jar file.
@mvstore_1086_p
@mvstore_1087_p
Each store may only be opened once within a JVM. When opening a store, the file is locked in exclusive mode, so that the file can only be changed from within one process. Files can be opened in read-only mode, in which case a shared lock is used.
Each store may only be opened once within a JVM. When opening a store, the file is locked in exclusive mode, so that the file can only be changed from within one process. Files can be opened in read-only mode, in which case a shared lock is used.
@mvstore_1087_p
@mvstore_1088_p
The persisted data can be backed up to a different file at any time, even during write operations (online backup). To do that, automatic disk space reuse needs to be first disabled, so that new data is always appended at the end of the file. Then, the file can be copied (the file handle is available to the application).
The persisted data can be backed up to a different file at any time, even during write operations (online backup). To do that, automatic disk space reuse needs to be first disabled, so that new data is always appended at the end of the file. Then, the file can be copied (the file handle is available to the application).
@mvstore_1088_h3
@mvstore_1089_h3
Encrypted Files
Encrypted Files
@mvstore_1089_p
@mvstore_1090_p
File encryption ensures the data can only be read with the correct password. Data can be encrypted as follows:
File encryption ensures the data can only be read with the correct password. Data can be encrypted as follows:
@mvstore_1090_p
@mvstore_1091_p
The following algorithms and settings are used:
The following algorithms and settings are used:
@mvstore_1091_li
@mvstore_1092_li
The password char array is cleared after use, to reduce the risk that the password is stolen even if the attacker has access to the main memory.
The password char array is cleared after use, to reduce the risk that the password is stolen even if the attacker has access to the main memory.
@mvstore_1092_li
@mvstore_1093_li
The password is hashed according to the PBKDF2 standard, using the SHA-256 hash algorithm.
The password is hashed according to the PBKDF2 standard, using the SHA-256 hash algorithm.
@mvstore_1093_li
@mvstore_1094_li
The length of the salt is 64 bits, so that an attacker can not use a pre-calculated password hash table (rainbow table). It is generated using a cryptographically secure random number generator.
The length of the salt is 64 bits, so that an attacker can not use a pre-calculated password hash table (rainbow table). It is generated using a cryptographically secure random number generator.
@mvstore_1094_li
@mvstore_1095_li
To speed up opening an encrypted stores on Android, the number of PBKDF2 iterations is 10. The higher the value, the better the protection against brute-force password cracking attacks, but the slower is opening a file.
To speed up opening an encrypted stores on Android, the number of PBKDF2 iterations is 10. The higher the value, the better the protection against brute-force password cracking attacks, but the slower is opening a file.
@mvstore_1095_li
@mvstore_1096_li
The file itself is encrypted using the standardized disk encryption mode XTS-AES. Only little more than one AES-128 round per block is needed.
The file itself is encrypted using the standardized disk encryption mode XTS-AES. Only little more than one AES-128 round per block is needed.
@mvstore_1096_h3
@mvstore_1097_h3
Tools
Tools
@mvstore_1097_p
@mvstore_1098_p
There is a tool (<code>MVStoreTool</code>) to dump the contents of a file.
There is a tool (<code>MVStoreTool</code>) to dump the contents of a file.
@mvstore_1098_h3
@mvstore_1099_h3
Exception Handling
Exception Handling
@mvstore_1099_p
@mvstore_1100_p
This tool does not throw checked exceptions. Instead, unchecked exceptions are thrown if needed. The error message always contains the version of the tool. The following exceptions can occur:
This tool does not throw checked exceptions. Instead, unchecked exceptions are thrown if needed. The error message always contains the version of the tool. The following exceptions can occur:
@mvstore_1100_code
@mvstore_1101_code
IllegalStateException
IllegalStateException
@mvstore_1101_li
@mvstore_1102_li
if a map was already closed or an IO exception occurred, for example if the file was locked, is already closed, could not be opened or closed, if reading or writing failed, if the file is corrupt, or if there is an internal error in the tool.
if a map was already closed or an IO exception occurred, for example if the file was locked, is already closed, could not be opened or closed, if reading or writing failed, if the file is corrupt, or if there is an internal error in the tool.
@mvstore_1102_code
@mvstore_1103_code
IllegalArgumentException
IllegalArgumentException
@mvstore_1103_li
@mvstore_1104_li
if a method was called with an illegal argument.
if a method was called with an illegal argument.
@mvstore_1104_code
@mvstore_1105_code
UnsupportedOperationException
UnsupportedOperationException
@mvstore_1105_li
@mvstore_1106_li
if a method was called that is not supported, for example trying to modify a read-only map or view.
if a method was called that is not supported, for example trying to modify a read-only map or view.
@mvstore_1106_code
@mvstore_1107_code
ConcurrentModificationException
ConcurrentModificationException
@mvstore_1107_li
@mvstore_1108_li
if the object is modified concurrently.
if the object is modified concurrently.
@mvstore_1108_h2
@mvstore_1109_h3
Table Engine for H2
@mvstore_1110_p
The plan is to use the MVStore as the default storage engine for the H2 database in the future (supporting SQL, JDBC, transactions, MVCC, and so on). This is work in progress. To try it out, append <code>;DEFAULT_TABLE_ENGINE=org.h2.mvstore.db.MVTableEngine</code> to the database URL. In general, functionality and performance should be similar than the current default storage engine (the page store). There are a few features that have not been implemented yet or are not complete:
@mvstore_1111_li
Changing the cache size.
@mvstore_1112_li
Two-phase commit.
@mvstore_1113_li
The database metadata is still stored in a <code>.h2.db</code> file.
@mvstore_1114_li
The database file(s) sometimes do not shrink as expected.
@mvstore_1115_h2
Similar Projects and Differences to Other Storage Engines
Similar Projects and Differences to Other Storage Engines
@mvstore_1109_p
@mvstore_1116_p
Unlike similar storage engines like LevelDB and Kyoto Cabinet, the MVStore is written in Java and can easily be embedded in a Java and Android application.
Unlike similar storage engines like LevelDB and Kyoto Cabinet, the MVStore is written in Java and can easily be embedded in a Java and Android application.
@mvstore_1110_p
@mvstore_1117_p
The MVStore is somewhat similar to the Berkeley DB Java Edition because it is also written in Java, and is also a log structured storage, but the H2 license is more liberal.
The MVStore is somewhat similar to the Berkeley DB Java Edition because it is also written in Java, and is also a log structured storage, but the H2 license is more liberal.
@mvstore_1111_p
@mvstore_1118_p
Like SQLite, the MVStore keeps all data in one file. Unlike SQLite, the MVStore uses is a log structured storage. The plan is to make the MVStore both easier to use as well as faster than SQLite. In a recent (very simple) test, the MVStore was about twice as fast as SQLite on Android.
Like SQLite, the MVStore keeps all data in one file. Unlike SQLite, the MVStore uses is a log structured storage. The plan is to make the MVStore both easier to use as well as faster than SQLite. In a recent (very simple) test, the MVStore was about twice as fast as SQLite on Android.
@mvstore_1112_p
@mvstore_1119_p
The API of the MVStore is similar to MapDB (previously known as JDBM) from Jan Kotek, and some code is shared between MapDB and JDBM. However, unlike MapDB, the MVStore uses is a log structured storage. The MVStore does not have a record size limit.
The API of the MVStore is similar to MapDB (previously known as JDBM) from Jan Kotek, and some code is shared between MapDB and JDBM. However, unlike MapDB, the MVStore uses is a log structured storage. The MVStore does not have a record size limit.
@mvstore_1113_h2
@mvstore_1120_h2
Current State
Current State
@mvstore_1114_p
@mvstore_1121_p
The code is still experimental at this stage. The API as well as the behavior may partially change. Features may be added and removed (even thought the main features will stay).
The code is still experimental at this stage. The API as well as the behavior may partially change. Features may be added and removed (even thought the main features will stay).
@mvstore_1115_h2
@mvstore_1122_h2
Requirements
Requirements
@mvstore_1116_p
@mvstore_1123_p
The MVStore is included in the latest H2 jar file.
The MVStore is included in the latest H2 jar file.
@mvstore_1117_p
@mvstore_1124_p
There are no special requirements to use it. The MVStore should run on any JVM as well as on Android.
There are no special requirements to use it. The MVStore should run on any JVM as well as on Android.
@mvstore_1118_p
@mvstore_1125_p
To build just the MVStore (without the database engine), run:
To build just the MVStore (without the database engine), run:
@mvstore_1119_p
@mvstore_1126_p
This will create the file <code>bin/h2mvstore-1.3.172.jar</code> (about 130 KB).
This will create the file <code>bin/h2mvstore-1.3.172.jar</code> (about 130 KB).
changelog_1007_li=Issue 468\:trunc(timestamp) could return the wrong value.
changelog_1007_li=Issue 468\:trunc(timestamp) could return the wrong value.
changelog_1008_li=Fixed a deadlock when updating LOB's concurrently. See TestLob.testDeadlock2().
changelog_1008_li=Fixed a deadlock when updating LOB's concurrently. See TestLob.testDeadlock2().
changelog_1009_li=Fixed a deadlock related to very large temporary result sets.
changelog_1009_li=Fixed a deadlock related to very large temporary result sets.
changelog_1010_li=Add "-list" command line option to Shell tool so that result-list-mode can be triggered when reading from a file
changelog_1010_li=Add "-list" command line option to Shell tool so that result-list-mode can be triggered when reading from a file.
changelog_1011_h2=Version 1.3.172 (2013-05-25)
changelog_1011_li=Issue 474\:H2 Mysql Compatibility code fails to ignore "COMMENT" in CREATE TABLE, patch from Aaron Azeckoski.
changelog_1012_li=Referential integrity\:when adding a referential integrity constraint failed, and if creating the constraint automatically created an index, this index was not removed.
changelog_1012_li=Issue 476\:Broken link in jaqu.html
changelog_1013_li=The auto-analyze feature now only reads 1000 rows per table instead of 10000.
changelog_1013_li=Fix potential UTF8 encoding issue in org.h2.store.FileStore, reported by Juerg Spiess.
changelog_1014_li=The optimization for IN(...) queries combined with OR could result in a strange exception of the type "column x must be included in the group by list".
changelog_1014_li=Improve error message when check constraint is broken, test case from Gili (cowwoc).
changelog_1015_li=Issue 454\:Use Charset for type-safety.
changelog_1015_li=Improve error message when we have a unique constraint violation, displays the offending key in the error message.
changelog_1016_li=Queries with both LIMIT and OFFSET could throw an IllegalArgumentException.
changelog_1016_li=Issue 478\:Support for "SHOW TRANSACTION ISOLATION LEVEL", patch from Andrew Franklin.
changelog_1017_li=MVStore\:multiple issues were fixed\:460, 461, 462, 464, 466.
changelog_1017_li=Issue 475\:PgServer\:add support for CancelRequest, patch from Andrew Franklin.
changelog_1018_li=MVStore\:larger stores (multiple GB) are now much faster.
changelog_1018_li=Issue 473\:PgServer missing -key option, patch from Andrew Franklin.
changelog_1019_li=When using local temporary tables and not dropping them manually before closing the session, and then killing the process could result in a database that couldn't be opened (except when using the recover tool).
changelog_1019_li=Issue 471\:CREATE VIEW does not check user rights, patch from Andrew Franklin.
changelog_1020_li=Support TRUNC(timestamp) for improved Oracle compatibility.
changelog_1020_li=Issue 477\:PgServer binary transmission of query params is unimplemented, patch from Andrew Franklin.
changelog_1021_li=Add support for CREATE TABLE TEST (ID BIGSERIAL) for PostgreSQL compatibility. Patch from Jesse Long.
changelog_1021_li=Issue 479\:Support for SUBSTRING without a FROM condition, patch from Andrew Franklin.
changelog_1022_li=Add new collation command SET BINARY_COLLATION UNSIGNED, helps with people testing BINARY columns in MySQL mode.
changelog_1022_li=Issue 472\:PgServer does not work with any recent Postgres JDBC driver, patch from Andrew Franklin.
changelog_1023_li=Issue 453\:ABBA race conditions in TABLE LINK connection sharing.
changelog_1023_li=Add syntax for passing additional parameters into custom TableEngine implementations.
changelog_1024_li=Issue 449\:Postgres Serial data type should not automatically be marked as primary key
changelog_1024_li=Issue 480\:Bugfix post issue \#475, \#477, patch from Andrew Franklin.
changelog_1025_li=Issue 481\:Further extensions to PgServer to support better support PG JDBC, patch from Andrew Franklin.
changelog_1026_li=Issue 389\:When there is a multi-column primary key, H2 does not seem to always pick the right index
changelog_1026_li=Add support for spatial datatype GEOMETRY.
changelog_1027_li=Issue 305\:Implement SELECT ... FOR FETCH ONLY
changelog_1027_li=Add support for in-memory spatial index.
changelog_1028_li=Issue 274\:Sybase/MSSQLServer compatibility - Add GETDATE and CHARINDEX system functions
changelog_1028_li=change the PageStore\#changeCount field from an int to a long, to cope with databases with very high transaction rates.
changelog_1029_li=Issue 274\:Sybase/MSSQLServer compatibility - swap parameters of CONVERT function.
changelog_1029_h2=Version 1.3.172 (2013-05-25)
changelog_1030_li=Issue 274\:Sybase/MSSQLServer compatibility - support index clause e.g. "select * from test (index table1_index)"
changelog_1030_li=Referential integrity\:when adding a referential integrity constraint failed, and if creating the constraint automatically created an index, this index was not removed.
changelog_1031_li=Fix bug in Optimizing SELECT * FROM A WHERE X\=1 OR X\=2 OR X\=3 into SELECT * FROM A WHERE X IN (1,2,3)
changelog_1031_li=The auto-analyze feature now only reads 1000 rows per table instead of 10000.
changelog_1032_li=Issue 442\:Groovy patch for SourceCompiler (function ALIAS)
changelog_1032_li=The optimization for IN(...) queries combined with OR could result in a strange exception of the type "column x must be included in the group by list".
changelog_1033_li=Issue 454\:Use Charset for type-safety.
changelog_1034_h2=Version 1.3.171 (2013-03-17)
changelog_1034_li=Queries with both LIMIT and OFFSET could throw an IllegalArgumentException.
changelog_1035_li=Security\:the TCP server did not correctly restrict access rights of clients in some cases. This was specially a problem when using the flag "tcpAllowOthers".
changelog_1035_li=MVStore\:multiple issues were fixed\:460, 461, 462, 464, 466.
changelog_1036_li=H2 Console\:the session timeout can now be configured using the system property "h2.consoleTimeout".
changelog_1036_li=MVStore\:larger stores (multiple GB) are now much faster.
changelog_1037_li=Issue 431\:Improved compatibility with MySQL\:support for "ENGINE\=InnoDB charset\=UTF8" when creating a table.
changelog_1037_li=When using local temporary tables and not dropping them manually before closing the session, and then killing the process could result in a database that couldn't be opened (except when using the recover tool).
changelog_1038_li=Issue 249\:Improved compatibility with MySQL in the MySQL mode\:now the methods DatabaseMetaData methods stores*Case*Identifiers return the same as MySQL when using the MySQL mode.
changelog_1038_li=Support TRUNC(timestamp) for improved Oracle compatibility.
changelog_1039_li=Issue 434\:H2 Console didn't work in the Chrome browser due to a wrong viewport argument.
changelog_1039_li=Add support for CREATE TABLE TEST (ID BIGSERIAL) for PostgreSQL compatibility. Patch from Jesse Long.
changelog_1040_li=There was a possibility that the .lock.db file was not deleted when the database was closed, which could slow down opening the database.
changelog_1040_li=Add new collation command SET BINARY_COLLATION UNSIGNED, helps with people testing BINARY columns in MySQL mode.
changelog_1041_li=The SQL script generated by the "script" command contained inconsistent newlines on Windows.
changelog_1041_li=Issue 453\:ABBA race conditions in TABLE LINK connection sharing.
changelog_1042_li=When using trace level 4 (SLF4J) in the server mode, a directory "trace.db" and an empty file was created on the client side. This is no longer made.
changelog_1042_li=Issue 449\:Postgres Serial data type should not automatically be marked as primary key
changelog_1043_li=Optimize IN(...) queries\:there was a bug in version 1.3.170 if the type of the left hand side didn't match the type of the right hand side. Fixed.
changelog_1044_li=Optimize IN(...) queries\:there was a bug in version 1.3.170 for comparison of the type "X IN(NULL, NULL)". Fixed.
changelog_1044_li=Issue 389\:When there is a multi-column primary key, H2 does not seem to always pick the right index
changelog_1045_li=Timestamps with timezone that were passed as a string were not always converted correctly. For example "2012-11-06T23\:00\:00.000Z" was converted to "2012-11-06" instead of to "2012-11-07" in the timezone CET. Thanks a lot to Steve Hruda for reporting the problem\!
changelog_1045_li=Issue 305\:Implement SELECT ... FOR FETCH ONLY
changelog_1046_li=New table engine "org.h2.mvstore.db.MVTableEngine" that internally uses the MVStore to persist data. To try it out, append ";DEFAULT_TABLE_ENGINE\=org.h2.mvstore.db.MVTableEngine" to the database URL. This is still very experimental, and many features are not supported yet. The data is stored in a file with the suffix ".mv.db".
changelog_1046_li=Issue 274\:Sybase/MSSQLServer compatibility - Add GETDATE and CHARINDEX system functions
changelog_1047_li=New connection setting "DEFAULT_TABLE_ENGINE" to use a specific table engine if none is set explicitly. This is to simplify testing the MVStore table engine.
changelog_1047_li=Issue 274\:Sybase/MSSQLServer compatibility - swap parameters of CONVERT function.
changelog_1048_li=MVStore\:encrypted stores are now supported. Only standardized algorithms are used\:PBKDF2, SHA-256, XTS-AES, AES-128.
changelog_1048_li=Issue 274\:Sybase/MSSQLServer compatibility - support index clause e.g. "select * from test (index table1_index)"
changelog_1049_li=MVStore\:improved API thanks to Simo Tripodi.
changelog_1049_li=Fix bug in Optimizing SELECT * FROM A WHERE X\=1 OR X\=2 OR X\=3 into SELECT * FROM A WHERE X IN (1,2,3)
changelog_1050_li=MVStore\:maps can now be renamed.
changelog_1050_li=Issue 442\:Groovy patch for SourceCompiler (function ALIAS)
changelog_1051_li=MVStore\:store the file header also at the end of each chunk, which results in a further reduced number of write operations.
changelog_1052_li=MVStore\:a map implementation that supports concurrent operations.
changelog_1052_h2=Version 1.3.171 (2013-03-17)
changelog_1053_li=MVStore\:unified exception handling; the version is included in the messages.
changelog_1053_li=Security\:the TCP server did not correctly restrict access rights of clients in some cases. This was specially a problem when using the flag "tcpAllowOthers".
changelog_1054_li=MVStore\:old data is now retained for 45 seconds by default.
changelog_1054_li=H2 Console\:the session timeout can now be configured using the system property "h2.consoleTimeout".
changelog_1055_li=MVStore\:compress is now disabled by default, and can be enabled on request.
changelog_1055_li=Issue 431\:Improved compatibility with MySQL\:support for "ENGINE\=InnoDB charset\=UTF8" when creating a table.
changelog_1056_li=Support ALTER TABLE ADD ... AFTER. Patch from Andrew Gaul (argaul at gmail.com). Fixes issue 401.
changelog_1056_li=Issue 249\:Improved compatibility with MySQL in the MySQL mode\:now the methods DatabaseMetaData methods stores*Case*Identifiers return the same as MySQL when using the MySQL mode.
changelog_1057_li=Improved OSGi support. H2 now registers itself as a DataSourceFactory service. Fixes issue 365.
changelog_1057_li=Issue 434\:H2 Console didn't work in the Chrome browser due to a wrong viewport argument.
changelog_1058_li=Add a DISK_SPACE_USED system function. Fixes issue 270.
changelog_1058_li=There was a possibility that the .lock.db file was not deleted when the database was closed, which could slow down opening the database.
changelog_1059_li=Fix a compile-time ambiguity when compiling with JDK7, thanks to a patch from Lukas Eder.
changelog_1059_li=The SQL script generated by the "script" command contained inconsistent newlines on Windows.
changelog_1060_li=Supporting dropping an index for Lucene full-text indexes.
changelog_1060_li=When using trace level 4 (SLF4J) in the server mode, a directory "trace.db" and an empty file was created on the client side. This is no longer made.
changelog_1061_li=Optimized performance for SELECT ... ORDER BY X LIMIT Y OFFSET Z queries for in-memory databases using partial sort (by Sergi Vladykin).
changelog_1061_li=Optimize IN(...) queries\:there was a bug in version 1.3.170 if the type of the left hand side didn't match the type of the right hand side. Fixed.
changelog_1062_li=Experimental off-heap memory storage engine "nioMemFS\:" and "nioMemLZF\:", suggestion from Mark Addleman.
changelog_1062_li=Optimize IN(...) queries\:there was a bug in version 1.3.170 for comparison of the type "X IN(NULL, NULL)". Fixed.
changelog_1063_li=Issue 438\: JdbcDatabaseMetaData.getSchemas() is no longer supported as of 1.3.169.
changelog_1063_li=Timestamps with timezone that were passed as a string were not always converted correctly. For example "2012-11-06T23\:00\:00.000Z" was converted to "2012-11-06" instead of to "2012-11-07" in the timezone CET. Thanks a lot to Steve Hruda for reporting the problem\!
changelog_1064_li=MySQL compatibility\: support for ALTER TABLE tableName MODIFY [COLUMN] columnName columnDef. Patch from Ville Koskela.
changelog_1064_li=New table engine "org.h2.mvstore.db.MVTableEngine" that internally uses the MVStore to persist data. To try it out, append ";DEFAULT_TABLE_ENGINE\=org.h2.mvstore.db.MVTableEngine" to the database URL. This is still very experimental, and many features are not supported yet. The data is stored in a file with the suffix ".mv.db".
changelog_1065_li=Issue 404\: SHOW COLUMNS FROM tableName does not work with ALLOW_LITERALS\=NUMBERS.
changelog_1065_li=New connection setting "DEFAULT_TABLE_ENGINE" to use a specific table engine if none is set explicitly. This is to simplify testing the MVStore table engine.
changelog_1066_li=Throw an explicit error to make it clear we don't support the TRIGGER combination of SELECT and FOR EACH ROW.
changelog_1066_li=MVStore\:encrypted stores are now supported. Only standardized algorithms are used\:PBKDF2, SHA-256, XTS-AES, AES-128.
changelog_1067_li=Issue 439\: Utils.sortTopN does not handle single-element arrays.
changelog_1067_li=MVStore\:improved API thanks to Simo Tripodi.
changelog_1068_h2=Version 1.3.170 (2012-11-30)
changelog_1068_li=MVStore\:maps can now be renamed.
changelog_1069_li=Issue 407\: The TriggerAdapter didn't work with CLOB and BLOB columns.
changelog_1069_li=MVStore\:store the file header also at the end of each chunk, which results in a further reduced number of write operations.
changelog_1070_li=PostgreSQL compatibility\: support for data types BIGSERIAL and SERIAL as an alias for AUTO_INCREMENT.
changelog_1070_li=MVStore\:a map implementation that supports concurrent operations.
changelog_1071_li=Issue 417\: H2 Console\: the web session timeout didn't work, resulting in a memory leak. This was only a problem if the H2 Console was run for a long time and many sessions were opened.
changelog_1071_li=MVStore\:unified exception handling; the version is included in the messages.
changelog_1072_li=Issue 412\: Running the Server tool with just the option "-browser" will now log a warning.
changelog_1072_li=MVStore\:old data is now retained for 45 seconds by default.
changelog_1073_li=Issue 411\:CloseWatcher registration was not concurrency-safe.
changelog_1073_li=MVStore\:compress is now disabled by default, and can be enabled on request.
changelog_1074_li=MySQL compatibility\:support for CONCAT_WS. Thanks a lot to litailang for the patch\!
changelog_1074_li=Support ALTER TABLE ADD ... AFTER. Patch from Andrew Gaul (argaul at gmail.com). Fixes issue 401.
changelog_1075_li=PostgreSQL compatibility\:support for EXTRACT(WEEK FROM dateColumn). Thanks to Prashant Bhat for the patch\!
changelog_1075_li=Improved OSGi support. H2 now registers itself as a DataSourceFactory service. Fixes issue 365.
changelog_1076_li=Fix for a bug where we would sometimes use the wrong unique constraint to validate foreign key constraints.
changelog_1076_li=Add a DISK_SPACE_USED system function. Fixes issue 270.
changelog_1077_li=Support BOM at the beginning of files for the RUNSCRIPT command
changelog_1077_li=Fix a compile-time ambiguity when compiling with JDK7, thanks to a patch from Lukas Eder.
changelog_1078_li=Fix in calling SET @X \=IDENTITY() where it would return NULL incorrectly
changelog_1078_li=Supporting dropping an index for Lucene full-text indexes.
changelog_1079_li=Fix ABBA deadlock between adding a constraint and the H2-Log-Writer thread.
changelog_1079_li=Optimized performance for SELECT ... ORDER BY X LIMIT Y OFFSET Z queries for in-memory databases using partial sort (by Sergi Vladykin).
changelog_1080_li=Optimize IN(...) queries where the values are constant and of the same type.
changelog_1080_li=Experimental off-heap memory storage engine "nioMemFS\:" and "nioMemLZF\:", suggestion from Mark Addleman.
changelog_1081_li=Restore tool\:the parameter "quiet" was not used and is now removed.
changelog_1081_li=Issue 438\: JdbcDatabaseMetaData.getSchemas() is no longer supported as of 1.3.169.
changelog_1082_li=Fix ConcurrentModificationException when creating tables and executing SHOW TABLES in parallel. Reported by Viktor Voytovych.
changelog_1082_li=MySQL compatibility\: support for ALTER TABLE tableName MODIFY [COLUMN] columnName columnDef. Patch from Ville Koskela.
changelog_1083_li=Serialization is now pluggable using the system property "h2.javaObjectSerializer". Thanks to Sergi Vladykin for the patch\!
changelog_1083_li=Issue 404\: SHOW COLUMNS FROM tableName does not work with ALLOW_LITERALS\=NUMBERS.
changelog_1084_h2=Version 1.3.169 (2012-09-09)
changelog_1084_li=Throw an explicit error to make it clear we don't support the TRIGGER combination of SELECT and FOR EACH ROW.
changelog_1085_li=The default jar file is now compiled for Java 6.
changelog_1085_li=Issue 439\: Utils.sortTopN does not handle single-element arrays.
changelog_1086_li=The new jar file will probably not end up in the central Maven repository in the next few weeks because Sonatype has disabled automatic synchronization from SourceForge (which they call 'legacy sync' now). It will probably take some time until this is sorted out. The H2 jar files are deployed to http\://h2database.com/m2-repo/com/h2database/h2/maven-metadata.xml and http\://hsql.sourceforge.net/m2-repo/com/h2database/h2/maven-metadata.xml as usual.
changelog_1086_h2=Version 1.3.170 (2012-11-30)
changelog_1087_li=A part of the documentation and the H2 Console has been changed to support the Apple retina display.
changelog_1087_li=Issue 407\: The TriggerAdapter didn't work with CLOB and BLOB columns.
changelog_1088_li=The CreateCluster tool could not be used if the source database contained a CLOB or BLOB. The root cause was that the TCP server did not synchronize on the session, which caused a problem when using the exclusive mode.
changelog_1088_li=PostgreSQL compatibility\: support for data types BIGSERIAL and SERIAL as an alias for AUTO_INCREMENT.
changelog_1089_li=Statement.getQueryTimeout()\:only the first call to this method will query the database. If the query timeout was changed in another way than calling setQueryTimeout, this method will always return the last value. This was changed because Hibernate calls getQueryTimeout() a lot.
changelog_1089_li=Issue 417\: H2 Console\: the web session timeout didn't work, resulting in a memory leak. This was only a problem if the H2 Console was run for a long time and many sessions were opened.
changelog_1090_li=Issue 416\:PreparedStatement.setNString throws AbstractMethodError. All implemented JDBC 4 methods that don't break compatibility with Java 5 are now included in the default jar file.
changelog_1090_li=Issue 412\: Running the Server tool with just the option "-browser" will now log a warning.
changelog_1091_li=Issue 414\:for some functions, the parameters were evaluated twice (for example "char(nextval(..))" ran "nextval(..)" twice).
changelog_1091_li=Issue 411\:CloseWatcher registration was not concurrency-safe.
changelog_1092_li=The ResultSetMetaData methods getSchemaName and getTableName could return null instead of "" (an empty string) as specified in the JDBC API.
changelog_1092_li=MySQL compatibility\:support for CONCAT_WS. Thanks a lot to litailang for the patch\!
changelog_1093_li=Added compatibility for "SET NAMES" query in MySQL compatibility mode.
changelog_1093_li=PostgreSQL compatibility\:support for EXTRACT(WEEK FROM dateColumn). Thanks to Prashant Bhat for the patch\!
changelog_1094_h2=Version 1.3.168 (2012-07-13)
changelog_1094_li=Fix for a bug where we would sometimes use the wrong unique constraint to validate foreign key constraints.
changelog_1095_li=The message "Transaction log could not be truncated" was sometimes written to the .trace.db file even if there was no problem truncating the transaction log.
changelog_1095_li=Support BOM at the beginning of files for the RUNSCRIPT command
changelog_1096_li=New system property "h2.serializeJavaObject" (default\:true) that allows to disable serializing Java objects, so that the objects compareTo and toString methods can be used.
changelog_1096_li=Fix in calling SET @X \=IDENTITY() where it would return NULL incorrectly
changelog_1097_li=Dylan has translated the H2 Console tool to Korean. Thanks a lot\!
changelog_1097_li=Fix ABBA deadlock between adding a constraint and the H2-Log-Writer thread.
changelog_1098_li=Executing the statement CREATE INDEX IF ALREADY EXISTS if the index already exists no longer fails for a read only database.
changelog_1098_li=Optimize IN(...) queries where the values are constant and of the same type.
changelog_1099_li=MVCC\:concurrently updating a row could result in the row to appear deleted in the second connection, if there are multiple unique indexes (or a primary key and at least one unique index). Thanks a lot to Teruo for the patch\!
changelog_1099_li=Restore tool\:the parameter "quiet" was not used and is now removed.
changelog_1100_li=Fulltext search\:in-memory Lucene indexes are now supported.
changelog_1100_li=Fix ConcurrentModificationException when creating tables and executing SHOW TABLES in parallel. Reported by Viktor Voytovych.
changelog_1101_li=Fulltext search\:UUID primary keys are now supported.
changelog_1101_li=Serialization is now pluggable using the system property "h2.javaObjectSerializer". Thanks to Sergi Vladykin for the patch\!
changelog_1102_li=Apache Tomcat 7.x will now longer log a warning when unloading the web application, if using a connection pool.
changelog_1102_h2=Version 1.3.169 (2012-09-09)
changelog_1103_li=H2 Console\:support the Midori browser (for Debian / Raspberry Pi)
changelog_1103_li=The default jar file is now compiled for Java 6.
changelog_1104_li=When opening a remote session, don't open a temporary file if the trace level is set to zero
changelog_1104_li=The new jar file will probably not end up in the central Maven repository in the next few weeks because Sonatype has disabled automatic synchronization from SourceForge (which they call 'legacy sync' now). It will probably take some time until this is sorted out. The H2 jar files are deployed to http\://h2database.com/m2-repo/com/h2database/h2/maven-metadata.xml and http\://hsql.sourceforge.net/m2-repo/com/h2database/h2/maven-metadata.xml as usual.
changelog_1105_li=Use HMAC for authenticating remote LOB id's, removing the need for maintaining a cache, and removing the limit on the number of LOBs per result set.
changelog_1105_li=A part of the documentation and the H2 Console has been changed to support the Apple retina display.
changelog_1106_li=H2 Console\:HTML and XML documents can now be edited in an updatable result set. There is (limited) support for editing multi-line documents.
changelog_1106_li=The CreateCluster tool could not be used if the source database contained a CLOB or BLOB. The root cause was that the TCP server did not synchronize on the session, which caused a problem when using the exclusive mode.
changelog_1107_h2=Version 1.3.167 (2012-05-23)
changelog_1107_li=Statement.getQueryTimeout()\:only the first call to this method will query the database. If the query timeout was changed in another way than calling setQueryTimeout, this method will always return the last value. This was changed because Hibernate calls getQueryTimeout() a lot.
changelog_1108_li=H2 Console\:when editing a row, an empty varchar column was replaced with a single space.
changelog_1108_li=Issue 416\:PreparedStatement.setNString throws AbstractMethodError. All implemented JDBC 4 methods that don't break compatibility with Java 5 are now included in the default jar file.
changelog_1109_li=Lukas Eder has updated the jOOQ documentation.
changelog_1109_li=Issue 414\:for some functions, the parameters were evaluated twice (for example "char(nextval(..))" ran "nextval(..)" twice).
changelog_1110_li=Some nested joins could not be executed, for example\:select * from (select * from (select * from a) a right join b b) c;
changelog_1110_li=The ResultSetMetaData methods getSchemaName and getTableName could return null instead of "" (an empty string) as specified in the JDBC API.
changelog_1111_li=MS SQL Server compatibility\:ISNULL is now an alias for IFNULL.
changelog_1111_li=Added compatibility for "SET NAMES" query in MySQL compatibility mode.
changelog_1112_li=Terrence Huang has completed the translation of the H2 Console tool to Chinese. Thanks a lot\!
changelog_1112_h2=Version 1.3.168 (2012-07-13)
changelog_1113_li=Server mode\:the number of CLOB / BLOB values that were cached on the server is now the maximum of\:5 times the SERVER_RESULT_SET_FETCH_SIZE (which is 100 by default), and SysProperties.SERVER_CACHED_OBJECTS.
changelog_1113_li=The message "Transaction log could not be truncated" was sometimes written to the .trace.db file even if there was no problem truncating the transaction log.
changelog_1114_li=In the trace file, the query execution time was incorrect in some cases, specially for the statement SET TRACE_LEVEL_FILE 2.
changelog_1114_li=New system property "h2.serializeJavaObject" (default\:true) that allows to disable serializing Java objects, so that the objects compareTo and toString methods can be used.
changelog_1115_li=The feature LOG_SIZE_LIMIT that was introduced in version 1.3.165 did not always work correctly (specially with regards to multithreading) and has been removed. The message "Transaction log could not be truncated" is still written to the .trace.db file if required.
changelog_1115_li=Dylan has translated the H2 Console tool to Korean. Thanks a lot\!
changelog_1116_li=Then reading from a resource using the prefix "classpath\:", the ContextClassLoader is now used if the resource can't be read otherwise.
changelog_1116_li=Executing the statement CREATE INDEX IF ALREADY EXISTS if the index already exists no longer fails for a read only database.
changelog_1117_li=DatabaseEventListener now calls setProgress whenever a statement starts and ends.
changelog_1117_li=MVCC\:concurrently updating a row could result in the row to appear deleted in the second connection, if there are multiple unique indexes (or a primary key and at least one unique index). Thanks a lot to Teruo for the patch\!
changelog_1118_li=DatabaseEventListener now calls setProgress periodically while a statement is running.
changelog_1118_li=Fulltext search\:in-memory Lucene indexes are now supported.
changelog_1119_li=The table INFORMATION_SCHEMA.FUNCTION_ALIASES now includes a column TYPE_NAME.
changelog_1119_li=Fulltext search\:UUID primary keys are now supported.
changelog_1120_li=Issue 378\: when using views, the wrong values were bound to a parameter in some cases.
changelog_1120_li=Apache Tomcat 7.x will now longer log a warning when unloading the web application, if using a connection pool.
changelog_1121_li=Terrence Huang has translated the error messages to Chinese. Thanks a lot\!
changelog_1121_li=H2 Console\:support the Midori browser (for Debian / Raspberry Pi)
changelog_1122_li=TRUNC was added as an alias for TRUNCATE.
changelog_1122_li=When opening a remote session, don't open a temporary file if the trace level is set to zero
changelog_1123_li=Small optimisation for accessing result values by column name.
changelog_1123_li=Use HMAC for authenticating remote LOB id's, removing the need for maintaining a cache, and removing the limit on the number of LOBs per result set.
changelog_1124_li=Fix for bug in Statement.getMoreResults(int)
changelog_1124_li=H2 Console\:HTML and XML documents can now be edited in an updatable result set. There is (limited) support for editing multi-line documents.
changelog_1125_li=The SCRIPT statements now supports filtering by schema and table. Thanks a lot to Jacob Qvortrup for providing the patch\!
changelog_1125_h2=Version 1.3.167 (2012-05-23)
changelog_1126_h2=Version 1.3.166 (2012-04-08)
changelog_1126_li=H2 Console\:when editing a row, an empty varchar column was replaced with a single space.
changelog_1127_li=Indexes on column that are larger than half the page size (wide indexes) could sometimes get corrupt, resulting in an ArrayIndexOutOfBoundsException in PageBtree.getRow or "Row not found" in PageBtreeLeaf. Also, such indexes used too much disk space.
changelog_1127_li=Lukas Eder has updated the jOOQ documentation.
changelog_1128_li=Server mode\:when retrieving more than 64 rows each containing a CLOB or BLOB, the error message "The object is already closed" was thrown.
changelog_1128_li=Some nested joins could not be executed, for example\:select * from (select * from (select * from a) a right join b b) c;
changelog_1129_li=ConvertTraceFile\:the time in the trace file is now parsed as a long.
changelog_1129_li=MS SQL Server compatibility\:ISNULL is now an alias for IFNULL.
changelog_1130_li=Invalid connection settings are now detected.
changelog_1130_li=Terrence Huang has completed the translation of the H2 Console tool to Chinese. Thanks a lot\!
changelog_1131_li=Issue 387\:WHERE condition getting pushed into sub-query with LIMIT.
changelog_1131_li=Server mode\:the number of CLOB / BLOB values that were cached on the server is now the maximum of\:5 times the SERVER_RESULT_SET_FETCH_SIZE (which is 100 by default), and SysProperties.SERVER_CACHED_OBJECTS.
changelog_1132_h2=Version 1.3.165 (2012-03-18)
changelog_1132_li=In the trace file, the query execution time was incorrect in some cases, specially for the statement SET TRACE_LEVEL_FILE 2.
changelog_1133_li=Better string representation for decimal values (for example 0.00000000 instead of 0E-26).
changelog_1133_li=The feature LOG_SIZE_LIMIT that was introduced in version 1.3.165 did not always work correctly (specially with regards to multithreading) and has been removed. The message "Transaction log could not be truncated" is still written to the .trace.db file if required.
changelog_1134_li=Prepared statements could only be re-used if the same data types were used the second time they were executed.
changelog_1134_li=Then reading from a resource using the prefix "classpath\:", the ContextClassLoader is now used if the resource can't be read otherwise.
changelog_1135_li=In error messages about referential constraint violation, the values are now included.
changelog_1135_li=DatabaseEventListener now calls setProgress whenever a statement starts and ends.
changelog_1136_li=SCRIPT and RUNSCRIPT\:the password can now be set using a prepared statement. Previously, it was required to be a literal in the SQL statement.
changelog_1136_li=DatabaseEventListener now calls setProgress periodically while a statement is running.
changelog_1137_li=MySQL compatibility\:SUBSTR with a negative start index now works like MySQL.
changelog_1137_li=The table INFORMATION_SCHEMA.FUNCTION_ALIASES now includes a column TYPE_NAME.
changelog_1138_li=When enabling autocommit, the transaction is now committed (as required by the JDBC API).
changelog_1138_li=Issue 378\: when using views, the wrong values were bound to a parameter in some cases.
changelog_1139_li=The shell script <code>h2.sh</code> did not work with spaces in the path. It also works now with quoted spaces in the argument list. Thanks a lot to Shimizu Fumiyuki for the patch\!
changelog_1139_li=Terrence Huang has translated the error messages to Chinese. Thanks a lot\!
changelog_1140_li=If the transaction log could not be truncated because of an uncommitted transaction, now "Transaction log could not be truncated" is written to the .trace.db file. Before, the database file was growing and it was hard to find out what the root cause was. To avoid the database file from growing, a new feature to automatically rollback the oldest transaction is available now. To enable it, append ;LOG_SIZE_LIMIT\=32 to the database URL (in that case, the oldest session is rolled back if the transaction log is 32 MB).
changelog_1140_li=TRUNC was added as an alias for TRUNCATE.
changelog_1141_li=ALTER TABLE ADD can now add more than one column at a time.
changelog_1141_li=Small optimisation for accessing result values by column name.
changelog_1142_li=Issue 380\:ALTER TABLE ADD FOREIGN KEY with an explicit index didn't verify the index can be used, which would lead to a NullPointerException later on.
changelog_1142_li=Fix for bug in Statement.getMoreResults(int)
changelog_1143_li=Issue 384\:the wrong kind of exception (NullPointerException) was thrown in a UNION query with an incorrect ORDER BY expression.
changelog_1143_li=The SCRIPT statements now supports filtering by schema and table. Thanks a lot to Jacob Qvortrup for providing the patch\!
changelog_1144_li=Issue 362\:support LIMIT in UPDATE statements.
changelog_1144_h2=Version 1.3.166 (2012-04-08)
changelog_1145_li=Browser\:if no default browser is set, Google Chrome is now used if available. If not available, then Konqueror, Netscape, or Opera is used if available (as before).
changelog_1145_li=Indexes on column that are larger than half the page size (wide indexes) could sometimes get corrupt, resulting in an ArrayIndexOutOfBoundsException in PageBtree.getRow or "Row not found" in PageBtreeLeaf. Also, such indexes used too much disk space.
changelog_1146_li=CSV tool\:new feature to disable writing the column header (option writeColumnHeader).
changelog_1146_li=Server mode\:when retrieving more than 64 rows each containing a CLOB or BLOB, the error message "The object is already closed" was thrown.
changelog_1147_li=CSV tool\:new feature to preserve the case sensitivity of column names (option caseSensitiveColumnNames).
changelog_1147_li=ConvertTraceFile\:the time in the trace file is now parsed as a long.
changelog_1148_li=PostgreSQL compatibility\:LOG(x) is base 10 in the PostgreSQL mode.
changelog_1148_li=Invalid connection settings are now detected.
changelog_1149_h2=Version 1.3.164 (2012-02-03)
changelog_1149_li=Issue 387\:WHERE condition getting pushed into sub-query with LIMIT.
changelog_1150_li=New built-in function ARRAY_CONTAINS.
changelog_1150_h2=Version 1.3.165 (2012-03-18)
changelog_1151_li=Some DatabaseMetaData methods didn't work when using ALLOW_LITERALS NONE.
changelog_1151_li=Better string representation for decimal values (for example 0.00000000 instead of 0E-26).
changelog_1152_li=Trying to convert a VARCHAR to UUID will now fail if the text contains a character that is not a hex digit, '-', or not a whitespace.
changelog_1152_li=Prepared statements could only be re-used if the same data types were used the second time they were executed.
changelog_1153_li=TriggerAdapter\:in "before" triggers, values can be changed using the ResultSet.updateX methods.
changelog_1153_li=In error messages about referential constraint violation, the values are now included.
changelog_1154_li=Creating a table with column data type NULL now works (even if not very useful).
changelog_1154_li=SCRIPT and RUNSCRIPT\:the password can now be set using a prepared statement. Previously, it was required to be a literal in the SQL statement.
changelog_1155_li=ALTER TABLE ALTER COLUMN no longer copies the data for widening conversions (for example if only the precision was increased) unless necessary.
changelog_1155_li=MySQL compatibility\:SUBSTR with a negative start index now works like MySQL.
changelog_1156_li=Multi-threaded kernel\:concurrently running an online backup and updating the database resulted in a broken (transactionally incorrect) backup file in some cases.
changelog_1156_li=When enabling autocommit, the transaction is now committed (as required by the JDBC API).
changelog_1157_li=The script created by SCRIPT DROP did not always work if multiple views existed that depend on each other.
changelog_1157_li=The shell script <code>h2.sh</code> did not work with spaces in the path. It also works now with quoted spaces in the argument list. Thanks a lot to Shimizu Fumiyuki for the patch\!
changelog_1158_li=MathUtils.getSecureRandom could log a warning to System.err in case the /dev/random is very slow, and the System.getProperties().toString() returned a string larger than 64 KB.
changelog_1158_li=If the transaction log could not be truncated because of an uncommitted transaction, now "Transaction log could not be truncated" is written to the .trace.db file. Before, the database file was growing and it was hard to find out what the root cause was. To avoid the database file from growing, a new feature to automatically rollback the oldest transaction is available now. To enable it, append ;LOG_SIZE_LIMIT\=32 to the database URL (in that case, the oldest session is rolled back if the transaction log is 32 MB).
changelog_1159_li=The database file locking mechanism "FS" (;FILE_LOCK\=FS) did not work on Linux since version 1.3.161.
changelog_1159_li=ALTER TABLE ADD can now add more than one column at a time.
changelog_1160_li=Sequences\:the functions NEXTVAL and CURRVAL did not work as expected when using quoted, mixed case sequence names.
changelog_1160_li=Issue 380\:ALTER TABLE ADD FOREIGN KEY with an explicit index didn't verify the index can be used, which would lead to a NullPointerException later on.
changelog_1161_li=The constructor for Csv objects is now public, and Csv.getInstance() is now deprecated.
changelog_1161_li=Issue 384\:the wrong kind of exception (NullPointerException) was thrown in a UNION query with an incorrect ORDER BY expression.
changelog_1162_li=SimpleResultSet\:updating a result set is now supported.
changelog_1162_li=Issue 362\:support LIMIT in UPDATE statements.
changelog_1163_li=Database URL\:extra semicolons are not supported.
changelog_1163_li=Browser\:if no default browser is set, Google Chrome is now used if available. If not available, then Konqueror, Netscape, or Opera is used if available (as before).
changelog_1164_h2=Version 1.3.163 (2011-12-30)
changelog_1164_li=CSV tool\:new feature to disable writing the column header (option writeColumnHeader).
changelog_1165_li=On out of disk space, the database could get corrupt sometimes, if later write operations succeeded. The same problem happened on other kinds of I/O exceptions (where one or some of the writes fail, but subsequent writes succeed). Now the file is closed on the first unsuccessful write operation, so that later requests fail consistently.
changelog_1165_li=CSV tool\:new feature to preserve the case sensitivity of column names (option caseSensitiveColumnNames).
changelog_1166_li=DatabaseEventListener.diskSpaceIsLow() is no longer supported because it can't be guaranteed that it always works correctly.
changelog_1166_li=PostgreSQL compatibility\:LOG(x) is base 10 in the PostgreSQL mode.
changelog_1167_li=XMLTEXT now supports an optional parameter to escape newlines.
changelog_1167_h2=Version 1.3.164 (2012-02-03)
changelog_1168_li=XMLNODE now support an optional parameter to disable indentation.
changelog_1168_li=New built-in function ARRAY_CONTAINS.
changelog_1169_li=Csv.write now formats date, time, and timestamp values using java.sql.Date / Time / Timestamp.toString(). Previously, ResultSet.getString() was used, which didn't work well for Oracle.
changelog_1169_li=Some DatabaseMetaData methods didn't work when using ALLOW_LITERALS NONE.
changelog_1170_li=The shell script <code>h2.sh</code> can now be run from within a different directory. Thanks a lot to Daniel Serodio for the patch\!
changelog_1170_li=Trying to convert a VARCHAR to UUID will now fail if the text contains a character that is not a hex digit, '-', or not a whitespace.
changelog_1171_li=The page size of a persistent database can now be queries using\:select * from information_schema.settings where name \='info.PAGE_SIZE'
changelog_1171_li=TriggerAdapter\:in "before" triggers, values can be changed using the ResultSet.updateX methods.
changelog_1172_li=In the server mode, BLOB and CLOB objects are no longer closed when the result set is closed (as required by the JDBC spec).
changelog_1172_li=Creating a table with column data type NULL now works (even if not very useful).
changelog_1173_li=ALTER TABLE ALTER COLUMN no longer copies the data for widening conversions (for example if only the precision was increased) unless necessary.
changelog_1174_li=Multi-threaded kernel\:concurrently running an online backup and updating the database resulted in a broken (transactionally incorrect) backup file in some cases.
changelog_1175_li=The script created by SCRIPT DROP did not always work if multiple views existed that depend on each other.
changelog_1176_li=MathUtils.getSecureRandom could log a warning to System.err in case the /dev/random is very slow, and the System.getProperties().toString() returned a string larger than 64 KB.
changelog_1177_li=The database file locking mechanism "FS" (;FILE_LOCK\=FS) did not work on Linux since version 1.3.161.
changelog_1178_li=Sequences\:the functions NEXTVAL and CURRVAL did not work as expected when using quoted, mixed case sequence names.
changelog_1179_li=The constructor for Csv objects is now public, and Csv.getInstance() is now deprecated.
changelog_1180_li=SimpleResultSet\:updating a result set is now supported.
changelog_1181_li=Database URL\:extra semicolons are not supported.
changelog_1182_h2=Version 1.3.163 (2011-12-30)
changelog_1183_li=On out of disk space, the database could get corrupt sometimes, if later write operations succeeded. The same problem happened on other kinds of I/O exceptions (where one or some of the writes fail, but subsequent writes succeed). Now the file is closed on the first unsuccessful write operation, so that later requests fail consistently.
changelog_1184_li=DatabaseEventListener.diskSpaceIsLow() is no longer supported because it can't be guaranteed that it always works correctly.
changelog_1185_li=XMLTEXT now supports an optional parameter to escape newlines.
changelog_1186_li=XMLNODE now support an optional parameter to disable indentation.
changelog_1187_li=Csv.write now formats date, time, and timestamp values using java.sql.Date / Time / Timestamp.toString(). Previously, ResultSet.getString() was used, which didn't work well for Oracle.
changelog_1188_li=The shell script <code>h2.sh</code> can now be run from within a different directory. Thanks a lot to Daniel Serodio for the patch\!
changelog_1189_li=The page size of a persistent database can now be queries using\:select * from information_schema.settings where name \='info.PAGE_SIZE'
changelog_1190_li=In the server mode, BLOB and CLOB objects are no longer closed when the result set is closed (as required by the JDBC spec).
cheatSheet_1000_h1=H2 Database Engine Cheat Sheet
cheatSheet_1000_h1=H2 Database Engine Cheat Sheet
cheatSheet_1001_h2=Using H2
cheatSheet_1001_h2=Using H2
cheatSheet_1002_a=H2
cheatSheet_1002_a=H2
...
@@ -1478,19 +1496,21 @@ features_1592_h2=Pluggable or User-Defined Tables
...
@@ -1478,19 +1496,21 @@ features_1592_h2=Pluggable or User-Defined Tables
features_1593_p=\ For situations where you need to expose other data-sources to the SQL engine as a table, there are "pluggable tables". For some examples, have a look at the code in <code>org.h2.test.db.TestTableEngines</code>.
features_1593_p=\ For situations where you need to expose other data-sources to the SQL engine as a table, there are "pluggable tables". For some examples, have a look at the code in <code>org.h2.test.db.TestTableEngines</code>.
features_1594_p=\ In order to create your own TableEngine, you need to implement the <code>org.h2.api.TableEngine</code> interface e.g. something like this\:
features_1594_p=\ In order to create your own TableEngine, you need to implement the <code>org.h2.api.TableEngine</code> interface e.g. something like this\:
features_1595_p=\ and then create the table from SQL like this\:
features_1595_p=\ and then create the table from SQL like this\:
features_1596_h2=Triggers
features_1596_p=\ It is also possible to pass in parameters to the table engine, like so\:
features_1597_p=\ This database supports Java triggers that are called before or after a row is updated, inserted or deleted. Triggers can be used for complex consistency checks, or to update related data in the database. It is also possible to use triggers to simulate materialized views. For a complete sample application, see <code>src/test/org/h2/samples/TriggerSample.java</code>. A Java trigger must implement the interface <code>org.h2.api.Trigger</code>. The trigger class must be available in the classpath of the database engine (when using the server mode, it must be in the classpath of the server).
features_1597_p=\ In which case the parameters are passed down in the tableEngineParams field of the CreateTableData object.
features_1598_p=\ The connection can be used to query or update data in other tables. The trigger then needs to be defined in the database\:
features_1598_h2=Triggers
features_1599_p=\ The trigger can be used to veto a change by throwing a <code>SQLException</code>.
features_1599_p=\ This database supports Java triggers that are called before or after a row is updated, inserted or deleted. Triggers can be used for complex consistency checks, or to update related data in the database. It is also possible to use triggers to simulate materialized views. For a complete sample application, see <code>src/test/org/h2/samples/TriggerSample.java</code>. A Java trigger must implement the interface <code>org.h2.api.Trigger</code>. The trigger class must be available in the classpath of the database engine (when using the server mode, it must be in the classpath of the server).
features_1600_p=\ As an alternative to implementing the <code>Trigger</code> interface, an application can extend the abstract class <code>org.h2.tools.TriggerAdapter</code>. This will allows to use the <code>ResultSet</code> interface within trigger implementations. In this case, only the <code>fire</code> method needs to be implemented\:
features_1600_p=\ The connection can be used to query or update data in other tables. The trigger then needs to be defined in the database\:
features_1601_h2=Compacting a Database
features_1601_p=\ The trigger can be used to veto a change by throwing a <code>SQLException</code>.
features_1602_p=\ Empty space in the database file re-used automatically. When closing the database, the database is automatically compacted for up to 200 milliseconds by default. To compact more, use the SQL statement SHUTDOWN COMPACT. However re-creating the database may further reduce the database size because this will re-build the indexes. Here is a sample function to do this\:
features_1602_p=\ As an alternative to implementing the <code>Trigger</code> interface, an application can extend the abstract class <code>org.h2.tools.TriggerAdapter</code>. This will allows to use the <code>ResultSet</code> interface within trigger implementations. In this case, only the <code>fire</code> method needs to be implemented\:
features_1603_p=\ See also the sample application <code>org.h2.samples.Compact</code>. The commands <code>SCRIPT / RUNSCRIPT</code> can be used as well to create a backup of a database and re-build the database from the script.
features_1603_h2=Compacting a Database
features_1604_h2=Cache Settings
features_1604_p=\ Empty space in the database file re-used automatically. When closing the database, the database is automatically compacted for up to 200 milliseconds by default. To compact more, use the SQL statement SHUTDOWN COMPACT. However re-creating the database may further reduce the database size because this will re-build the indexes. Here is a sample function to do this\:
features_1605_p=\ The database keeps most frequently used data in the main memory. The amount of memory used for caching can be changed using the setting <code>CACHE_SIZE</code>. This setting can be set in the database connection URL (<code>jdbc\:h2\:~/test;CACHE_SIZE\=131072</code>), or it can be changed at runtime using <code>SET CACHE_SIZE size</code>. The size of the cache, as represented by <code>CACHE_SIZE</code> is measured in KB, with each KB being 1024 bytes. This setting has no effect for in-memory databases. For persistent databases, the setting is stored in the database and re-used when the database is opened the next time. However, when opening an existing database, the cache size is set to at most half the amount of memory available for the virtual machine (Runtime.getRuntime().maxMemory()), even if the cache size setting stored in the database is larger; however the setting stored in the database is kept. Setting the cache size in the database URL or explicitly using <code>SET CACHE_SIZE</code> overrides this value (even if larger than the physical memory). To get the current used maximum cache size, use the query <code>SELECT * FROM INFORMATION_SCHEMA.SETTINGS WHERE NAME \='info.CACHE_MAX_SIZE'</code>
features_1605_p=\ See also the sample application <code>org.h2.samples.Compact</code>. The commands <code>SCRIPT / RUNSCRIPT</code> can be used as well to create a backup of a database and re-build the database from the script.
features_1606_p=\ An experimental scan-resistant cache algorithm "Two Queue" (2Q) is available. To enable it, append <code>;CACHE_TYPE\=TQ</code> to the database URL. The cache might not actually improve performance. If you plan to use it, please run your own test cases first.
features_1606_h2=Cache Settings
features_1607_p=\ Also included is an experimental second level soft reference cache. Rows in this cache are only garbage collected on low memory. By default the second level cache is disabled. To enable it, use the prefix <code>SOFT_</code>. Example\:<code>jdbc\:h2\:~/test;CACHE_TYPE\=SOFT_LRU</code>. The cache might not actually improve performance. If you plan to use it, please run your own test cases first.
features_1607_p=\ The database keeps most frequently used data in the main memory. The amount of memory used for caching can be changed using the setting <code>CACHE_SIZE</code>. This setting can be set in the database connection URL (<code>jdbc\:h2\:~/test;CACHE_SIZE\=131072</code>), or it can be changed at runtime using <code>SET CACHE_SIZE size</code>. The size of the cache, as represented by <code>CACHE_SIZE</code> is measured in KB, with each KB being 1024 bytes. This setting has no effect for in-memory databases. For persistent databases, the setting is stored in the database and re-used when the database is opened the next time. However, when opening an existing database, the cache size is set to at most half the amount of memory available for the virtual machine (Runtime.getRuntime().maxMemory()), even if the cache size setting stored in the database is larger; however the setting stored in the database is kept. Setting the cache size in the database URL or explicitly using <code>SET CACHE_SIZE</code> overrides this value (even if larger than the physical memory). To get the current used maximum cache size, use the query <code>SELECT * FROM INFORMATION_SCHEMA.SETTINGS WHERE NAME \='info.CACHE_MAX_SIZE'</code>
features_1608_p=\ To get information about page reads and writes, and the current caching algorithm in use, call <code>SELECT * FROM INFORMATION_SCHEMA.SETTINGS</code>. The number of pages read / written is listed.
features_1608_p=\ An experimental scan-resistant cache algorithm "Two Queue" (2Q) is available. To enable it, append <code>;CACHE_TYPE\=TQ</code> to the database URL. The cache might not actually improve performance. If you plan to use it, please run your own test cases first.
features_1609_p=\ Also included is an experimental second level soft reference cache. Rows in this cache are only garbage collected on low memory. By default the second level cache is disabled. To enable it, use the prefix <code>SOFT_</code>. Example\:<code>jdbc\:h2\:~/test;CACHE_TYPE\=SOFT_LRU</code>. The cache might not actually improve performance. If you plan to use it, please run your own test cases first.
features_1610_p=\ To get information about page reads and writes, and the current caching algorithm in use, call <code>SELECT * FROM INFORMATION_SCHEMA.SETTINGS</code>. The number of pages read / written is listed.
fragments_1000_div=\ <span id \="goTop"onclick\="window.scrollTo(0,0)"style\="color\:\#fff; position\:fixed; font-size\: 20px; cursor\: pointer;">&\#x25b2;</span>
fragments_1000_div=\ <span id \="goTop"onclick\="window.scrollTo(0,0)"style\="color\:\#fff; position\:fixed; font-size\: 20px; cursor\: pointer;">&\#x25b2;</span>
mvstore_1019_a=\ Similar Projects and Differences to Other Storage Engines
mvstore_1019_div=\ - <a href\="\#tableEngine">Table Engine for H2</a>
mvstore_1020_a=\ Current State
mvstore_1020_a=\ Similar Projects and Differences to Other Storage Engines
mvstore_1021_a=\ Requirements
mvstore_1021_a=\ Current State
mvstore_1022_h2=Overview
mvstore_1022_a=\ Requirements
mvstore_1023_p=\ The MVStore is work in progress, and is planned to be the next storage subsystem of H2. But it can be also directly within an application, without using JDBC or SQL.
mvstore_1023_h2=Overview
mvstore_1024_li=MVStore stands for "multi-version store".
mvstore_1024_p=\ The MVStore is work in progress, and is planned to be the next storage subsystem of H2. But it can be also directly within an application, without using JDBC or SQL.
mvstore_1025_li=Each store contains a number of maps (using the <code>java.util.Map</code> interface).
mvstore_1025_li=MVStore stands for "multi-version store".
mvstore_1026_li=Both file-based persistence and in-memory operation are supported.
mvstore_1026_li=Each store contains a number of maps (using the <code>java.util.Map</code> interface).
mvstore_1027_li=It is intended to be fast, simple to use, and small.
mvstore_1027_li=Both file-based persistence and in-memory operation are supported.
mvstore_1028_li=Old versions of the data can be read concurrently with all other operations.
mvstore_1028_li=It is intended to be fast, simple to use, and small.
mvstore_1029_li=Transaction are supported (including concurrent transactions and 2-phase commit).
mvstore_1029_li=Old versions of the data can be read concurrently with all other operations.
mvstore_1030_li=The tool is very modular. It supports pluggable data types / serialization, pluggable map implementations (B-tree, R-tree, concurrent B-tree currently), BLOB storage, and a file system abstraction to support encrypted files and zip files.
mvstore_1030_li=Transaction are supported (including concurrent transactions and 2-phase commit).
mvstore_1031_h2=Example Code
mvstore_1031_li=The tool is very modular. It supports pluggable data types / serialization, pluggable map implementations (B-tree, R-tree, concurrent B-tree currently), BLOB storage, and a file system abstraction to support encrypted files and zip files.
mvstore_1032_p=\ The following sample code show how to create a store, open a map, add some data, and access the current and an old version\:
mvstore_1032_h2=Example Code
mvstore_1033_h2=Store Builder
mvstore_1033_p=\ The following sample code show how to create a store, open a map, add some data, and access the current and an old version\:
mvstore_1034_p=\ The <code>MVStore.Builder</code> provides a fluid interface to build a store if more complex configuration options are used. The following code contains all supported configuration options\:
mvstore_1034_h2=Store Builder
mvstore_1035_li=cacheSizeMB\:the cache size in MB.
mvstore_1035_p=\ The <code>MVStore.Builder</code> provides a fluid interface to build a store if more complex configuration options are used. The following code contains all supported configuration options\:
mvstore_1036_li=compressData\:compress the data when storing.
mvstore_1036_li=cacheSizeMB\:the cache size in MB.
mvstore_1037_li=encryptionKey\:the encryption key for file encryption.
mvstore_1037_li=compressData\:compress the data when storing.
mvstore_1038_li=fileName\:the name of the file, for file based stores.
mvstore_1038_li=encryptionKey\:the encryption key for file encryption.
mvstore_1039_li=readOnly\:open the file in read-only mode.
mvstore_1039_li=fileName\:the name of the file, for file based stores.
mvstore_1040_li=writeBufferSize\:the size of the write buffer in MB.
mvstore_1040_li=readOnly\:open the file in read-only mode.
mvstore_1041_li=writeDelay\:the maximum delay until committed changes are stored (unless stored explicitly).
mvstore_1041_li=writeBufferSize\:the size of the write buffer in MB.
mvstore_1042_h2=R-Tree
mvstore_1042_li=writeDelay\:the maximum delay until committed changes are stored (unless stored explicitly).
mvstore_1043_p=\ The <code>MVRTreeMap</code> is an R-tree implementation that supports fast spatial queries. It can be used as follows\:
mvstore_1043_h2=R-Tree
mvstore_1044_p=\ The default number of dimensions is 2. To use a different number of dimensions, call <code>new MVRTreeMap.Builder<String>().dimensions(3)</code>. The minimum number of dimensions is 1, the maximum is 255.
mvstore_1044_p=\ The <code>MVRTreeMap</code> is an R-tree implementation that supports fast spatial queries. It can be used as follows\:
mvstore_1045_h2=Features
mvstore_1045_p=\ The default number of dimensions is 2. To use a different number of dimensions, call <code>new MVRTreeMap.Builder<String>().dimensions(3)</code>. The minimum number of dimensions is 1, the maximum is 255.
mvstore_1046_h3=Maps
mvstore_1046_h2=Features
mvstore_1047_p=\ Each store supports a set of named maps. A map is sorted by key, and supports the common lookup operations, including access to the first and last key, iterate over some or all keys, and so on.
mvstore_1047_h3=Maps
mvstore_1048_p=\ Also supported, and very uncommon for maps, is fast index lookup\:the keys of the map can be accessed like a list (get the key at the given index, get the index of a certain key). That means getting the median of two keys is trivial, and range of keys can be counted very quickly. The iterator supports fast skipping. This is possible because internally, each map is organized in the form of a counted B+-tree.
mvstore_1048_p=\ Each store supports a set of named maps. A map is sorted by key, and supports the common lookup operations, including access to the first and last key, iterate over some or all keys, and so on.
mvstore_1049_p=\ In database terms, a map can be used like a table, where the key of the map is the primary key of the table, and the value is the row. A map can also represent an index, where the key of the map is the key of the index, and the value of the map is the primary key of the table (for non-unique indexes, the key of the map must also contain the primary key).
mvstore_1049_p=\ Also supported, and very uncommon for maps, is fast index lookup\:the keys of the map can be accessed like a list (get the key at the given index, get the index of a certain key). That means getting the median of two keys is trivial, and range of keys can be counted very quickly. The iterator supports fast skipping. This is possible because internally, each map is organized in the form of a counted B+-tree.
mvstore_1050_h3=Versions
mvstore_1050_p=\ In database terms, a map can be used like a table, where the key of the map is the primary key of the table, and the value is the row. A map can also represent an index, where the key of the map is the key of the index, and the value of the map is the primary key of the table (for non-unique indexes, the key of the map must also contain the primary key).
mvstore_1051_p=\ Multiple versions are supported. A version is a snapshot of all the data of all maps at a given point in time. A transaction is a number of actions between two versions.
mvstore_1051_h3=Versions
mvstore_1052_p=\ Versions are not immediately persisted; instead, only the version counter is incremented. If there is a change after switching to a new version, a snapshot of the old version is kept in memory, so that it can still be read.
mvstore_1052_p=\ Multiple versions are supported. A version is a snapshot of all the data of all maps at a given point in time. A transaction is a number of actions between two versions.
mvstore_1053_p=\ Old persisted versions are readable until the old data was explicitly overwritten. Creating a snapshot is fast\:only the pages that are changed after a snapshot are copied. This behavior is also called COW (copy on write).
mvstore_1053_p=\ Versions are not immediately persisted; instead, only the version counter is incremented. If there is a change after switching to a new version, a snapshot of the old version is kept in memory, so that it can still be read.
mvstore_1054_p=\ Rollback is supported (rollback to any old in-memory version or an old persisted version).
mvstore_1054_p=\ Old persisted versions are readable until the old data was explicitly overwritten. Creating a snapshot is fast\:only the pages that are changed after a snapshot are copied. This behavior is also called COW (copy on write).
mvstore_1055_h3=Transactions
mvstore_1055_p=\ Rollback is supported (rollback to any old in-memory version or an old persisted version).
mvstore_1056_p=\ The multi-version support is the basis for the transaction support. In the simple case, when only one transaction is open at a time, rolling back the transaction only requires to revert to an old version.
mvstore_1056_h3=Transactions
mvstore_1057_p=\ To support multiple concurrent open transactions, a transaction utility is included, the <code>TransactionStore</code>. This utility stores the changed entries in a separate map, similar to a transaction log (except that only the key of a changed row is stored, and the entries of a transaction are removed when the transaction is committed). The storage overhead of this utility is very small compared to the overhead of a regular transaction log. The tool supports PostgreSQL style "read committed" transaction isolation. There is no limit on the size of a transaction (the log is not kept in memory). The tool supports savepoints, two-phase commit, and other features typically available in a database.
mvstore_1057_p=\ The multi-version support is the basis for the transaction support. In the simple case, when only one transaction is open at a time, rolling back the transaction only requires to revert to an old version.
mvstore_1058_h3=In-Memory Performance and Usage
mvstore_1058_p=\ To support multiple concurrent open transactions, a transaction utility is included, the <code>TransactionStore</code>. This utility stores the changed entries in a separate map, similar to a transaction log (except that only the key of a changed row is stored, and the entries of a transaction are removed when the transaction is committed). The storage overhead of this utility is very small compared to the overhead of a regular transaction log. The tool supports PostgreSQL style "read committed" transaction isolation. There is no limit on the size of a transaction (the log is not kept in memory). The tool supports savepoints, two-phase commit, and other features typically available in a database.
mvstore_1059_p=\ Performance of in-memory operations is comparable with <code>java.util.TreeMap</code> (many operations are actually faster), but usually slower than <code>java.util.HashMap</code>.
mvstore_1059_h3=In-Memory Performance and Usage
mvstore_1060_p=\ The memory overhead for large maps is slightly better than for the regular map implementations, but there is a higher overhead per map. For maps with less than 25 entries, the regular map implementations use less memory on average.
mvstore_1060_p=\ Performance of in-memory operations is comparable with <code>java.util.TreeMap</code> (many operations are actually faster), but usually slower than <code>java.util.HashMap</code>.
mvstore_1061_p=\ If no file name is specified, the store operates purely in memory. Except for persisting data, all features are supported in this mode (multi-versioning, index lookup, R-tree and so on). If a file name is specified, all operations occur in memory (with the same performance characteristics) until data is persisted.
mvstore_1061_p=\ The memory overhead for large maps is slightly better than for the regular map implementations, but there is a higher overhead per map. For maps with less than 25 entries, the regular map implementations use less memory on average.
mvstore_1062_h3=Pluggable Data Types
mvstore_1062_p=\ If no file name is specified, the store operates purely in memory. Except for persisting data, all features are supported in this mode (multi-versioning, index lookup, R-tree and so on). If a file name is specified, all operations occur in memory (with the same performance characteristics) until data is persisted.
mvstore_1063_p=\ Serialization is pluggable. The default serialization currently supports many common data types, and uses Java serialization for other objects. The following classes are currently directly supported\:<code>Boolean, Byte, Short, Character, Integer, Long, Float, Double, BigInteger, BigDecimal, String, UUID, Date</code> and arrays (both primitive arrays and object arrays).
mvstore_1063_h3=Pluggable Data Types
mvstore_1064_p=\ Parameterized data types are supported (for example one could build a string data type that limits the length for some reason).
mvstore_1064_p=\ Serialization is pluggable. The default serialization currently supports many common data types, and uses Java serialization for other objects. The following classes are currently directly supported\:<code>Boolean, Byte, Short, Character, Integer, Long, Float, Double, BigInteger, BigDecimal, String, UUID, Date</code> and arrays (both primitive arrays and object arrays).
mvstore_1065_p=\ The storage engine itself does not have any length limits, so that keys, values, pages, and chunks can be very big (as big as fits in memory). Also, there is no inherent limit to the number of maps and chunks. Due to using a log structured storage, there is no special case handling for large keys or pages.
mvstore_1065_p=\ Parameterized data types are supported (for example one could build a string data type that limits the length for some reason).
mvstore_1066_h3=BLOB Support
mvstore_1066_p=\ The storage engine itself does not have any length limits, so that keys, values, pages, and chunks can be very big (as big as fits in memory). Also, there is no inherent limit to the number of maps and chunks. Due to using a log structured storage, there is no special case handling for large keys or pages.
mvstore_1067_p=\ There is a mechanism that stores large binary objects by splitting them into smaller blocks. This allows to store objects that don't fit in memory. Streaming as well as random access reads on such objects are supported. This tool is written on top of the store (only using the map interface).
mvstore_1067_h3=BLOB Support
mvstore_1068_h3=R-Tree and Pluggable Map Implementations
mvstore_1068_p=\ There is a mechanism that stores large binary objects by splitting them into smaller blocks. This allows to store objects that don't fit in memory. Streaming as well as random access reads on such objects are supported. This tool is written on top of the store (only using the map interface).
mvstore_1069_p=\ The map implementation is pluggable. In addition to the default <code>MVMap</code> (multi-version map), there is a multi-version R-tree map implementation for spatial operations (contain and intersection; nearest neighbor is not yet implemented).
mvstore_1069_h3=R-Tree and Pluggable Map Implementations
mvstore_1070_h3=Concurrent Operations and Caching
mvstore_1070_p=\ The map implementation is pluggable. In addition to the default <code>MVMap</code> (multi-version map), there is a multi-version R-tree map implementation for spatial operations (contain and intersection; nearest neighbor is not yet implemented).
mvstore_1071_p=\ The default map implementation supports concurrent reads on old versions of the data. All such read operations can occur in parallel. Concurrent reads from the page cache, as well as concurrent reads from the file system are supported.
mvstore_1071_h3=Concurrent Operations and Caching
mvstore_1072_p=\ Storing changes can occur concurrently to modifying the data, as it operates on a snapshot.
mvstore_1072_p=\ The default map implementation supports concurrent reads on old versions of the data. All such read operations can occur in parallel. Concurrent reads from the page cache, as well as concurrent reads from the file system are supported.
mvstore_1073_p=\ Caching is done on the page level. The page cache is a concurrent LIRS cache, which should be resistant against scan operations.
mvstore_1073_p=\ Storing changes can occur concurrently to modifying the data, as it operates on a snapshot.
mvstore_1074_p=\ The default map implementation does not support concurrent modification operations on a map (the same as <code>HashMap</code> and <code>TreeMap</code>). Similar to those classes, the map tries to detect concurrent modification.
mvstore_1074_p=\ Caching is done on the page level. The page cache is a concurrent LIRS cache, which should be resistant against scan operations.
mvstore_1075_p=\ With the <code>MVMapConcurrent</code> implementation, read operations even on the newest version can happen concurrently with all other operations, without risk of corruption. This comes with slightly reduced speed in single threaded mode, the same as with other <code>ConcurrentHashMap</code> implementations. Write operations first read the relevant area from disk to memory (this can happen concurrently), and only then modify the data. The in-memory part of write operations is synchronized.
mvstore_1075_p=\ The default map implementation does not support concurrent modification operations on a map (the same as <code>HashMap</code> and <code>TreeMap</code>). Similar to those classes, the map tries to detect concurrent modification.
mvstore_1076_p=\ For fully scalable concurrent write operations to a map (in-memory and to disk), the map could be split into multiple maps in different stores ('sharding'). The plan is to add such a mechanism later when needed.
mvstore_1076_p=\ With the <code>MVMapConcurrent</code> implementation, read operations even on the newest version can happen concurrently with all other operations, without risk of corruption. This comes with slightly reduced speed in single threaded mode, the same as with other <code>ConcurrentHashMap</code> implementations. Write operations first read the relevant area from disk to memory (this can happen concurrently), and only then modify the data. The in-memory part of write operations is synchronized.
mvstore_1077_h3=Log Structured Storage
mvstore_1077_p=\ For fully scalable concurrent write operations to a map (in-memory and to disk), the map could be split into multiple maps in different stores ('sharding'). The plan is to add such a mechanism later when needed.
mvstore_1078_p=\ Changes are buffered in memory, and once enough changes have accumulated, they are written in one continuous disk write operation. (According to a test, write throughput of a common SSD gets higher the larger the block size, until a block size of 2 MB, and then does not further increase.) By default, committed changes are automatically written once every second in a background thread, even if only little data was changed. Changes can also be written explicitly by calling <code>store()</code>. To avoid out of memory, uncommitted changes are also written when needed, however they are rolled back when closing the store, or at the latest (when the store was not correctly closed) when opening the store.
mvstore_1078_h3=Log Structured Storage
mvstore_1079_p=\ When storing, all changed pages are serialized, optionally compressed using the LZF algorithm, and written sequentially to a free area of the file. Each such change set is called a chunk. All parent pages of the changed B-trees are stored in this chunk as well, so that each chunk also contains the root of each changed map (which is the entry point to read this version of the data). There is no separate index\:all data is stored as a list of pages. Per store, there is one additional map that contains the metadata (the list of maps, where the root page of each map is stored, and the list of chunks).
mvstore_1079_p=\ Changes are buffered in memory, and once enough changes have accumulated, they are written in one continuous disk write operation. (According to a test, write throughput of a common SSD gets higher the larger the block size, until a block size of 2 MB, and then does not further increase.) By default, committed changes are automatically written once every second in a background thread, even if only little data was changed. Changes can also be written explicitly by calling <code>store()</code>. To avoid out of memory, uncommitted changes are also written when needed, however they are rolled back when closing the store, or at the latest (when the store was not correctly closed) when opening the store.
mvstore_1080_p=\ There are usually two write operations per chunk\:one to store the chunk data (the pages), and one to update the file header (so it points to the latest chunk). If the chunk is appended at the end of the file, the file header is only written at the end of the chunk.
mvstore_1080_p=\ When storing, all changed pages are serialized, optionally compressed using the LZF algorithm, and written sequentially to a free area of the file. Each such change set is called a chunk. All parent pages of the changed B-trees are stored in this chunk as well, so that each chunk also contains the root of each changed map (which is the entry point to read this version of the data). There is no separate index\:all data is stored as a list of pages. Per store, there is one additional map that contains the metadata (the list of maps, where the root page of each map is stored, and the list of chunks).
mvstore_1081_p=\ There is no transaction log, no undo log, and there are no in-place updates (however unused chunks are overwritten by default).
mvstore_1081_p=\ There are usually two write operations per chunk\:one to store the chunk data (the pages), and one to update the file header (so it points to the latest chunk). If the chunk is appended at the end of the file, the file header is only written at the end of the chunk.
mvstore_1082_p=\ Old data is kept for at least 45 seconds (configurable), so that there are no explicit sync operations required to guarantee data consistency, but an application can also sync explicitly when needed. To reuse disk space, the chunks with the lowest amount of live data are compacted (the live data is simply stored again in the next chunk). To improve data locality and disk space usage, the plan is to automatically defragment and compact data.
mvstore_1082_p=\ There is no transaction log, no undo log, and there are no in-place updates (however unused chunks are overwritten by default).
mvstore_1083_p=\ Compared to traditional storage engines (that use a transaction log, undo log, and main storage area), the log structured storage is simpler, more flexible, and typically needs less disk operations per change, as data is only written once instead of twice or 3 times, and because the B-tree pages are always full (they are stored next to each other) and can be easily compressed. But temporarily, disk space usage might actually be a bit higher than for a regular database, as disk space is not immediately re-used (there are no in-place updates).
mvstore_1083_p=\ Old data is kept for at least 45 seconds (configurable), so that there are no explicit sync operations required to guarantee data consistency, but an application can also sync explicitly when needed. To reuse disk space, the chunks with the lowest amount of live data are compacted (the live data is simply stored again in the next chunk). To improve data locality and disk space usage, the plan is to automatically defragment and compact data.
mvstore_1084_h3=File System Abstraction, File Locking and Online Backup
mvstore_1084_p=\ Compared to traditional storage engines (that use a transaction log, undo log, and main storage area), the log structured storage is simpler, more flexible, and typically needs less disk operations per change, as data is only written once instead of twice or 3 times, and because the B-tree pages are always full (they are stored next to each other) and can be easily compressed. But temporarily, disk space usage might actually be a bit higher than for a regular database, as disk space is not immediately re-used (there are no in-place updates).
mvstore_1085_p=\ The file system is pluggable (the same file system abstraction is used as H2 uses). The file can be encrypted using an encrypting file system. Other file system implementations support reading from a compressed zip or jar file.
mvstore_1085_h3=File System Abstraction, File Locking and Online Backup
mvstore_1086_p=\ Each store may only be opened once within a JVM. When opening a store, the file is locked in exclusive mode, so that the file can only be changed from within one process. Files can be opened in read-only mode, in which case a shared lock is used.
mvstore_1086_p=\ The file system is pluggable (the same file system abstraction is used as H2 uses). The file can be encrypted using an encrypting file system. Other file system implementations support reading from a compressed zip or jar file.
mvstore_1087_p=\ The persisted data can be backed up to a different file at any time, even during write operations (online backup). To do that, automatic disk space reuse needs to be first disabled, so that new data is always appended at the end of the file. Then, the file can be copied (the file handle is available to the application).
mvstore_1087_p=\ Each store may only be opened once within a JVM. When opening a store, the file is locked in exclusive mode, so that the file can only be changed from within one process. Files can be opened in read-only mode, in which case a shared lock is used.
mvstore_1088_h3=Encrypted Files
mvstore_1088_p=\ The persisted data can be backed up to a different file at any time, even during write operations (online backup). To do that, automatic disk space reuse needs to be first disabled, so that new data is always appended at the end of the file. Then, the file can be copied (the file handle is available to the application).
mvstore_1089_p=\ File encryption ensures the data can only be read with the correct password. Data can be encrypted as follows\:
mvstore_1089_h3=Encrypted Files
mvstore_1090_p=\ The following algorithms and settings are used\:
mvstore_1090_p=\ File encryption ensures the data can only be read with the correct password. Data can be encrypted as follows\:
mvstore_1091_li=The password char array is cleared after use, to reduce the risk that the password is stolen even if the attacker has access to the main memory.
mvstore_1091_p=\ The following algorithms and settings are used\:
mvstore_1092_li=The password is hashed according to the PBKDF2 standard, using the SHA-256 hash algorithm.
mvstore_1092_li=The password char array is cleared after use, to reduce the risk that the password is stolen even if the attacker has access to the main memory.
mvstore_1093_li=The length of the salt is 64 bits, so that an attacker can not use a pre-calculated password hash table (rainbow table). It is generated using a cryptographically secure random number generator.
mvstore_1093_li=The password is hashed according to the PBKDF2 standard, using the SHA-256 hash algorithm.
mvstore_1094_li=To speed up opening an encrypted stores on Android, the number of PBKDF2 iterations is 10. The higher the value, the better the protection against brute-force password cracking attacks, but the slower is opening a file.
mvstore_1094_li=The length of the salt is 64 bits, so that an attacker can not use a pre-calculated password hash table (rainbow table). It is generated using a cryptographically secure random number generator.
mvstore_1095_li=The file itself is encrypted using the standardized disk encryption mode XTS-AES. Only little more than one AES-128 round per block is needed.
mvstore_1095_li=To speed up opening an encrypted stores on Android, the number of PBKDF2 iterations is 10. The higher the value, the better the protection against brute-force password cracking attacks, but the slower is opening a file.
mvstore_1096_h3=Tools
mvstore_1096_li=The file itself is encrypted using the standardized disk encryption mode XTS-AES. Only little more than one AES-128 round per block is needed.
mvstore_1097_p=\ There is a tool (<code>MVStoreTool</code>) to dump the contents of a file.
mvstore_1097_h3=Tools
mvstore_1098_h3=Exception Handling
mvstore_1098_p=\ There is a tool (<code>MVStoreTool</code>) to dump the contents of a file.
mvstore_1099_p=\ This tool does not throw checked exceptions. Instead, unchecked exceptions are thrown if needed. The error message always contains the version of the tool. The following exceptions can occur\:
mvstore_1099_h3=Exception Handling
mvstore_1100_code=IllegalStateException
mvstore_1100_p=\ This tool does not throw checked exceptions. Instead, unchecked exceptions are thrown if needed. The error message always contains the version of the tool. The following exceptions can occur\:
mvstore_1101_li=\ if a map was already closed or an IO exception occurred, for example if the file was locked, is already closed, could not be opened or closed, if reading or writing failed, if the file is corrupt, or if there is an internal error in the tool.
mvstore_1101_code=IllegalStateException
mvstore_1102_code=IllegalArgumentException
mvstore_1102_li=\ if a map was already closed or an IO exception occurred, for example if the file was locked, is already closed, could not be opened or closed, if reading or writing failed, if the file is corrupt, or if there is an internal error in the tool.
mvstore_1103_li=\ if a method was called with an illegal argument.
mvstore_1103_code=IllegalArgumentException
mvstore_1104_code=UnsupportedOperationException
mvstore_1104_li=\ if a method was called with an illegal argument.
mvstore_1105_li=\ if a method was called that is not supported, for example trying to modify a read-only map or view.
mvstore_1105_code=UnsupportedOperationException
mvstore_1106_code=ConcurrentModificationException
mvstore_1106_li=\ if a method was called that is not supported, for example trying to modify a read-only map or view.
mvstore_1107_li=\ if the object is modified concurrently.
mvstore_1107_code=ConcurrentModificationException
mvstore_1108_h2=Similar Projects and Differences to Other Storage Engines
mvstore_1108_li=\ if the object is modified concurrently.
mvstore_1109_p=\ Unlike similar storage engines like LevelDB and Kyoto Cabinet, the MVStore is written in Java and can easily be embedded in a Java and Android application.
mvstore_1109_h3=Table Engine for H2
mvstore_1110_p=\ The MVStore is somewhat similar to the Berkeley DB Java Edition because it is also written in Java, and is also a log structured storage, but the H2 license is more liberal.
mvstore_1110_p=\ The plan is to use the MVStore as the default storage engine for the H2 database in the future (supporting SQL, JDBC, transactions, MVCC, and so on). This is work in progress. To try it out, append <code>;DEFAULT_TABLE_ENGINE\=org.h2.mvstore.db.MVTableEngine</code> to the database URL. In general, functionality and performance should be similar than the current default storage engine (the page store). There are a few features that have not been implemented yet or are not complete\:
mvstore_1111_p=\ Like SQLite, the MVStore keeps all data in one file. Unlike SQLite, the MVStore uses is a log structured storage. The plan is to make the MVStore both easier to use as well as faster than SQLite. In a recent (very simple) test, the MVStore was about twice as fast as SQLite on Android.
mvstore_1111_li=Changing the cache size.
mvstore_1112_p=\ The API of the MVStore is similar to MapDB (previously known as JDBM) from Jan Kotek, and some code is shared between MapDB and JDBM. However, unlike MapDB, the MVStore uses is a log structured storage. The MVStore does not have a record size limit.
mvstore_1112_li=Two-phase commit.
mvstore_1113_h2=Current State
mvstore_1113_li=The database metadata is still stored in a <code>.h2.db</code> file.
mvstore_1114_p=\ The code is still experimental at this stage. The API as well as the behavior may partially change. Features may be added and removed (even thought the main features will stay).
mvstore_1114_li=The database file(s) sometimes do not shrink as expected.
mvstore_1115_h2=Requirements
mvstore_1115_h2=Similar Projects and Differences to Other Storage Engines
mvstore_1116_p=\ The MVStore is included in the latest H2 jar file.
mvstore_1116_p=\ Unlike similar storage engines like LevelDB and Kyoto Cabinet, the MVStore is written in Java and can easily be embedded in a Java and Android application.
mvstore_1117_p=\ There are no special requirements to use it. The MVStore should run on any JVM as well as on Android.
mvstore_1117_p=\ The MVStore is somewhat similar to the Berkeley DB Java Edition because it is also written in Java, and is also a log structured storage, but the H2 license is more liberal.
mvstore_1118_p=\ To build just the MVStore (without the database engine), run\:
mvstore_1118_p=\ Like SQLite, the MVStore keeps all data in one file. Unlike SQLite, the MVStore uses is a log structured storage. The plan is to make the MVStore both easier to use as well as faster than SQLite. In a recent (very simple) test, the MVStore was about twice as fast as SQLite on Android.
mvstore_1119_p=\ This will create the file <code>bin/h2mvstore-1.3.172.jar</code> (about 130 KB).
mvstore_1119_p=\ The API of the MVStore is similar to MapDB (previously known as JDBM) from Jan Kotek, and some code is shared between MapDB and JDBM. However, unlike MapDB, the MVStore uses is a log structured storage. The MVStore does not have a record size limit.
mvstore_1120_h2=Current State
mvstore_1121_p=\ The code is still experimental at this stage. The API as well as the behavior may partially change. Features may be added and removed (even thought the main features will stay).
mvstore_1122_h2=Requirements
mvstore_1123_p=\ The MVStore is included in the latest H2 jar file.
mvstore_1124_p=\ There are no special requirements to use it. The MVStore should run on any JVM as well as on Android.
mvstore_1125_p=\ To build just the MVStore (without the database engine), run\:
mvstore_1126_p=\ This will create the file <code>bin/h2mvstore-1.3.172.jar</code> (about 130 KB).
@@ -38,4 +38,4 @@ org.h2.tools.Script.main=Options are case sensitive. Supported options are\:\n[-
...
@@ -38,4 +38,4 @@ org.h2.tools.Script.main=Options are case sensitive. Supported options are\:\n[-
org.h2.tools.Server=Starts the H2 Console (web-) server, TCP, and PG server.
org.h2.tools.Server=Starts the H2 Console (web-) server, TCP, and PG server.
org.h2.tools.Server.main=When running without options, -tcp, -web, -browser and -pg are started.\nOptions are case sensitive. Supported options are\:\n[-help] or [-?] Print the list of options\n[-web] Start the web server with the H2 Console\n[-webAllowOthers] Allow other computers to connect - see below\n[-webDaemon] Use a daemon thread\n[-webPort <port>] The port (default\:8082)\n[-webSSL] Use encrypted (HTTPS) connections\n[-browser] Start a browser connecting to the web server\n[-tcp] Start the TCP server\n[-tcpAllowOthers] Allow other computers to connect - see below\n[-tcpDaemon] Use a daemon thread\n[-tcpPort <port>] The port (default\:9092)\n[-tcpSSL] Use encrypted (SSL) connections\n[-tcpPassword <pwd>] The password for shutting down a TCP server\n[-tcpShutdown "<url>"] Stop the TCP server; example\:tcp\://localhost\n[-tcpShutdownForce] Do not wait until all connections are closed\n[-pg] Start the PG server\n[-pgAllowOthers] Allow other computers to connect - see below\n[-pgDaemon] Use a daemon thread\n[-pgPort <port>] The port (default\:5435)\n[-properties "<dir>"] Server properties (default\:~, disable\:null)\n[-baseDir <dir>] The base directory for H2 databases (all servers)\n[-ifExists] Only existing databases may be opened (all servers)\n[-trace] Print additional trace information (all servers)\nThe options -xAllowOthers are potentially risky.\nFor details, see Advanced Topics / Protection against Remote Access.
org.h2.tools.Server.main=When running without options, -tcp, -web, -browser and -pg are started.\nOptions are case sensitive. Supported options are\:\n[-help] or [-?] Print the list of options\n[-web] Start the web server with the H2 Console\n[-webAllowOthers] Allow other computers to connect - see below\n[-webDaemon] Use a daemon thread\n[-webPort <port>] The port (default\:8082)\n[-webSSL] Use encrypted (HTTPS) connections\n[-browser] Start a browser connecting to the web server\n[-tcp] Start the TCP server\n[-tcpAllowOthers] Allow other computers to connect - see below\n[-tcpDaemon] Use a daemon thread\n[-tcpPort <port>] The port (default\:9092)\n[-tcpSSL] Use encrypted (SSL) connections\n[-tcpPassword <pwd>] The password for shutting down a TCP server\n[-tcpShutdown "<url>"] Stop the TCP server; example\:tcp\://localhost\n[-tcpShutdownForce] Do not wait until all connections are closed\n[-pg] Start the PG server\n[-pgAllowOthers] Allow other computers to connect - see below\n[-pgDaemon] Use a daemon thread\n[-pgPort <port>] The port (default\:5435)\n[-properties "<dir>"] Server properties (default\:~, disable\:null)\n[-baseDir <dir>] The base directory for H2 databases (all servers)\n[-ifExists] Only existing databases may be opened (all servers)\n[-trace] Print additional trace information (all servers)\nThe options -xAllowOthers are potentially risky.\nFor details, see Advanced Topics / Protection against Remote Access.
org.h2.tools.Shell=Interactive command line tool to access a database using JDBC.
org.h2.tools.Shell=Interactive command line tool to access a database using JDBC.
org.h2.tools.Shell.main=Options are case sensitive. Supported options are\:\n[-help] or [-?] Print the list of options\n[-list] Enable list mode for printing results\n[-url "<url>"] The database URL (jdbc\:h2\:...)\n[-user <user>] The user name\n[-password <pwd>] The password\n[-driver <class>] The JDBC driver class to use (not required in most cases)\n[-sql "<statements>"] Execute the SQL statements and exit\n[-properties "<dir>"] Load the server properties from this directory\nIf special characters don't work as expected, you may need to use\n-Dfile.encoding\=UTF-8 (Mac OS X) or CP850 (Windows).
org.h2.tools.Shell.main=Options are case sensitive. Supported options are\:\n[-help] or [-?] Print the list of options\n[-url "<url>"] The database URL (jdbc\:h2\:...)\n[-user <user>] The user name\n[-password <pwd>] The password\n[-driver <class>] The JDBC driver class to use (not required in most cases)\n[-sql "<statements>"] Execute the SQL statements and exit\n[-properties "<dir>"] Load the server properties from this directory\nIf special characters don't work as expected, you may need to use\n-Dfile.encoding\=UTF-8 (Mac OS X) or CP850 (Windows).
