AdvancedResult SetsLarge Objects Linked Tables Recursive Queries Transaction Isolation Multi-Version Concurrency Control (MVCC) Clustering / High Availability Two Phase Commit Compatibility Standards Compliance Run as Windows Service ODBC Driver Using H2 in Microsoft .NET ACID Durability Problems Using the Recover Tool File Locking Protocols File Locking Method 'Serialized' Using Passwords Password Hash Protection against SQL Injection Protection against Remote Access Restricting Class Loading and Usage Security Protocols SSL/TLS Connections Universally Unique Identifiers (UUID) Settings Read from System Properties Setting the Server Bind Address Pluggable File System Database Upgrade Limits and Limitations Glossary and Links Result SetsStatements that Return a Result Set
The following statements return a result set: Limiting the Number of Rows
Before the result is returned to the application, all rows are read by the database.
Server side cursors are not supported currently.
If only the first few rows are interesting for the application, then the
result set size should be limited to improve the performance.
This can be done using Large Result Sets and External Sorting
For large result set, the result is buffered to disk. The threshold can be defined using the statement
Large ObjectsStoring and Reading Large Objects
If it is possible that the objects don't fit into memory, then the data type
CLOB (for textual data) or BLOB (for binary data) should be used.
For these data types, the objects are not fully read into memory, by using streams.
To store a BLOB, use When to use CLOB/BLOBThis database stores large LOB (CLOB and BLOB) objects as separate files. Small LOB objects are stored in-place, the threshold can be set using MAX_LENGTH_INPLACE_LOB, but there is still an overhead to use CLOB/BLOB. Because of this, BLOB and CLOB should never be used for columns with a maximum size below about 200 bytes. The best threshold depends on the use case; reading in-place objects is faster than reading from separate files, but slows down the performance of operations that don't involve this column. Large Object CompressionCLOB and BLOB values can be compressed by using SET COMPRESS_LOB. The LZF algorithm is faster but needs more disk space. By default compression is disabled, which usually speeds up write operations. If you store many large compressible values such as XML, HTML, text, and uncompressed binary files, then compressing can save a lot of disk space (sometimes more than 50%), and read operations may even be faster. Linked Tables
This database supports linked tables, which means tables that don't exist in the current database but
are just links to another database. To create such a link, use the
CREATE LINKED TABLE LINK('org.postgresql.Driver', 'jdbc:postgresql:test', 'sa', 'sa', 'TEST');
You can then access the table in the usual way.
Whenever the linked table is accessed, the database issues specific queries over JDBC.
Using the example above, if you issue the query To view the statements that are executed against the target table, set the trace level to 3.
If multiple linked tables point to the same database (using the same database URL), the connection
is shared. To disable this, set the system property The statement CREATE LINKED TABLE supports an optional schema name parameter. Transaction IsolationTransaction isolation is provided for all data manipulation language (DML) statements. Most data definition language (DDL) statements commit the current transaction. See the Grammar for details. This database supports the following transaction isolation levels:
When using the isolation level 'serializable', dirty reads, non-repeatable reads, and phantom reads are prohibited.
Table Level LockingThe database allows multiple concurrent connections to the same database. To make sure all connections only see consistent data, table level locking is used by default. This mechanism does not allow high concurrency, but is very fast. Shared locks and exclusive locks are supported. Before reading from a table, the database tries to add a shared lock to the table (this is only possible if there is no exclusive lock on the object by another connection). If the shared lock is added successfully, the table can be read. It is allowed that other connections also have a shared lock on the same object. If a connection wants to write to a table (update or delete a row), an exclusive lock is required. To get the exclusive lock, other connection must not have any locks on the object. After the connection commits, all locks are released. This database keeps all locks in memory. When a lock is released, and multiple connections are waiting for it, one of them is picked at random. Lock TimeoutIf a connection cannot get a lock on an object, the connection waits for some amount of time (the lock timeout). During this time, hopefully the connection holding the lock commits and it is then possible to get the lock. If this is not possible because the other connection does not release the lock for some time, the unsuccessful connection will get a lock timeout exception. The lock timeout can be set individually for each connection. Multi-Version Concurrency Control (MVCC)
The MVCC feature allows higher concurrency than using (table level or row level) locks.
When using MVCC in this database, delete, insert and update operations will only issue a
shared lock on the table. An exclusive lock is still used when adding or removing columns,
when dropping the table, and when using
To use the MVCC feature, append jdbc:h2:~/test;MVCC=TRUE
MVCC is disabled by default. The MVCC feature is not fully tested yet.
The limitations of the MVCC mode are: it can not be used at the same time as
Clustering / High AvailabilityThis database supports a simple clustering / high availability mechanism. The architecture is: two database servers run on two different computers, and on both computers is a copy of the same database. If both servers run, each database operation is executed on both computers. If one server fails (power, hardware or network failure), the other server can still continue to work. From this point on, the operations will be executed only on one server until the other server is back up.
Clustering can only be used in the server mode (the embedded mode does not support clustering).
The cluster can be re-created using the To initialize the cluster, use the following steps:
Using the CreateCluster ToolTo understand how clustering works, please try out the following example. In this example, the two databases reside on the same computer, but usually, the databases will be on different servers.
Detect Which Cluster Instances are RunningTo find out which cluster nodes are currently running, execute the following SQL statement: SELECT VALUE FROM INFORMATION_SCHEMA.SETTINGS WHERE NAME='CLUSTER'
If the result is Clustering Algorithm and Limitations
Read-only queries are only executed against the first cluster node, but all other statements are
executed against all nodes. There is currently no load balancing made to avoid problems with
transactions. The following functions may yield different results on different cluster nodes and must be
executed with care: When using the cluster modes, result sets are read fully in memory by the client, so that there is no problem if the server dies that executed the query. Result sets must fit in memory on the client side.
The SQL statement Two Phase CommitThe two phase commit protocol is supported. 2-phase-commit works as follows:
CompatibilityThis database is (up to a certain point) compatible to other databases such as HSQLDB, MySQL and PostgreSQL. There are certain areas where H2 is incompatible. Transaction Commit when Autocommit is OnAt this time, this database engine commits a transaction (if autocommit is switched on) just before returning the result. For a query, this means the transaction is committed even before the application scans through the result set, and before the result set is closed. Other database engines may commit the transaction in this case when the result set is closed. Keywords / Reserved WordsThere is a list of keywords that can't be used as identifiers (table names, column names and so on), unless they are quoted (surrounded with double quotes). The list is currently:
Certain words of this list are keywords because they are functions that can be used without '()' for compatibility,
for example Standards ComplianceThis database tries to be as much standard compliant as possible. For the SQL language, ANSI/ISO is the main standard. There are several versions that refer to the release date: SQL-92, SQL:1999, and SQL:2003. Unfortunately, the standard documentation is not freely available. Another problem is that important features are not standardized. Whenever this is the case, this database tries to be compatible to other databases. Run as Windows Service
Using a native wrapper / adapter, Java applications can be run as a Windows Service.
There are various tools available to do that. The Java Service Wrapper from
Tanuki Software, Inc.
is included in the installation. Batch files are provided to install, start, stop and uninstall the
H2 Database Engine Service. This service contains the TCP Server and the H2 Console web application.
The batch files are located in the directory Install the Service
The service needs to be registered as a Windows Service first.
To do that, double click on Start the Service
You can start the H2 Database Engine Service using the service manager of Windows,
or by double clicking on Connect to the H2 Console
After installing and starting the service, you can connect to the H2 Console application using a browser.
Double clicking on Stop the Service
To stop the service, double click on Uninstall the Service
To uninstall the service, double click on Additional JDBC drivers
To use other databases (for example MySQL), the location of the JDBC drivers of those databases need to be
added to the environment variables ODBC DriverThis database does not come with its own ODBC driver at this time, but it supports the PostgreSQL network protocol. Therefore, the PostgreSQL ODBC driver can be used. Support for the PostgreSQL network protocol is quite new and should be viewed as experimental. It should not be used for production applications.
To use the PostgreSQL ODBC driver on 64 bit versions of Windows,
first run ODBC Installation
First, the ODBC driver must be installed.
Any recent PostgreSQL ODBC driver should work, however version 8.2 ( Starting the ServerAfter installing the ODBC driver, start the H2 Server using the command line: java -cp h2*.jar org.h2.tools.Server
The PG Server (PG for PostgreSQL protocol) is started as well.
By default, databases are stored in the current working directory where the server is started.
Use java -cp h2*.jar org.h2.tools.Server -baseDir ~ The PG server can be started and stopped from within a Java application as follows:
Server server = Server.createPgServer("-baseDir", "~");
server.start();
...
server.stop();
By default, only connections from localhost are allowed. To allow remote connections, use
ODBC Configuration
After installing the driver, a new Data Source must be added. In Windows,
run
To improve performance, please enable 'server side prepare' under Options / Datasource / Page 2 / Server side prepare. Afterwards, you may use this data source. PG Protocol Support LimitationsAt this time, only a subset of the PostgreSQL network protocol is implemented. Also, there may be compatibility problems on the SQL level, with the catalog, or with text encoding. Problems are fixed as they are found. Currently, statements can not be canceled when using the PG protocol. Also, H2 does not provide index meta over ODBC. PostgreSQL ODBC Driver Setup requires a database password; that means it is not possible to connect to H2 databases without password. This is a limitation of the ODBC driver. Security ConsiderationsCurrently, the PG Server does not support challenge response or encrypt passwords. This may be a problem if an attacker can listen to the data transferred between the ODBC driver and the server, because the password is readable to the attacker. Also, it is currently not possible to use encrypted SSL connections. Therefore the ODBC driver should not be used where security is important. Using Microsoft AccessWhen using Microsoft Access to edit data in a linked H2 table, you may need to enable the following option: Tools - Options - Edit/Find - ODBC fields. Using H2 in Microsoft .NETThe database can be used from Microsoft .NET even without using Java, by using IKVM.NET. You can access a H2 database on .NET using the JDBC API, or using the ADO.NET interface. Using the ADO.NET API on .NETAn implementation of the ADO.NET interface is available in the open source project H2Sharp. Using the JDBC API on .NET
If you want your C# application use H2, you need to add the
using System;
using java.sql;
class Test
{
static public void Main()
{
org.h2.Driver.load();
Connection conn = DriverManager.getConnection("jdbc:h2:~/test", "sa", "sa");
Statement stat = conn.createStatement();
ResultSet rs = stat.executeQuery("SELECT 'Hello World'");
while (rs.next())
{
Console.WriteLine(rs.getString(1));
}
}
}
ACIDIn the database world, ACID stands for:
AtomicityTransactions in this database are always atomic. ConsistencyBy default, this database is always in a consistent state. Referential integrity rules are enforced except when explicitly disabled. IsolationFor H2, as with most other database systems, the default isolation level is 'read committed'. This provides better performance, but also means that transactions are not completely isolated. H2 supports the transaction isolation levels 'serializable', 'read committed', and 'read uncommitted'. DurabilityThis database does not guarantee that all committed transactions survive a power failure. Tests show that all databases sometimes lose transactions on power failure (for details, see below). Where losing transactions is not acceptable, a laptop or UPS (uninterruptible power supply) should be used. If durability is required for all possible cases of hardware failure, clustering should be used, such as the H2 clustering mode. Durability Problems
Complete durability means all committed transaction survive a power failure.
Some databases claim they can guarantee durability, but such claims are wrong.
A durability test was run against H2, HSQLDB, PostgreSQL, and Derby.
All of those databases sometimes lose committed transactions.
The test is included in the H2 download, see Ways to (Not) Achieve Durability
Making sure that committed transactions are not lost is more complicated than it seems first.
To guarantee complete durability, a database must ensure that the log record is on the hard drive
before the commit call returns. To do that, databases use different methods. One
is to use the 'synchronous write' file access mode. In Java,
A test (
Calling
By default, MySQL calls Trying to flush hard drive buffers is hard, and if you do the performance is very bad. First you need to make sure that the hard drive actually flushes all buffers. Tests show that this can not be done in a reliable way. Then the maximum number of transactions is around 60 per second. Because of those reasons, the default behavior of H2 is to delay writing committed transactions.
In H2, after a power failure, a bit more than one second of committed transactions may be lost.
To change the behavior, use Running the Durability Test
To test the durability / non-durability of this and other databases, you can use the test application
in the package Using the Recover Tool
The java -cp h2*.jar org.h2.tools.Recover
For each database in the current directory, a text file will be created.
This file contains raw insert statements (for the data) and data definition (DDL) statements to recreate
the schema of the database. This file can be executed using the
The File Locking ProtocolsMultiple concurrent connections to the same database are supported, however a database file can only be open for reading and writing (in embedded mode) by one process at the same time. Otherwise, the processes would overwrite each others data and corrupt the database file. To protect against this problem, whenever a database is opened, a lock file is created to signal other processes that the database is in use. If the database is closed, or if the process that opened the database stops normally, this lock file is deleted. In special cases (if the process did not terminate normally, for example because there was a power failure), the lock file is not deleted by the process that created it. That means the existence of the lock file is not a safe protocol for file locking. However, this software uses a challenge-response protocol to protect the database files. There are two methods (algorithms) implemented to provide both security (that is, the same database files cannot be opened by two processes at the same time) and simplicity (that is, the lock file does not need to be deleted manually by the user). The two methods are 'file method' and 'socket methods'. The file locking protocols (except the file locking method 'FS') have the following limitation: if a shared file system is used, and the machine with the lock owner is sent to sleep (standby or hibernate), another machine may take over. If the machine that originally held the lock wakes up, the database may become corrupt. If this situation can occur, the application must ensure the database is closed when the application is put to sleep. File Locking Method 'File'The default method for database file locking is the 'File Method'. The algorithm is:
This algorithm is tested with over 100 concurrent threads. In some cases, when there are many concurrent threads trying to lock the database, they block each other (meaning the file cannot be locked by any of them) for some time. However, the file never gets locked by two threads at the same time. However using that many concurrent threads / processes is not the common use case. Generally, an application should throw an error to the user if it cannot open a database, and not try again in a (fast) loop. File Locking Method 'Socket'
There is a second locking mechanism implemented, but disabled by default.
To use it, append
This method does not require a watchdog thread actively polling (reading) the same file every second. The problem with this method is, if the file is stored on a network share, two processes (running on different computers) could still open the same database files, if they do not have a direct TCP/IP connection. File Locking Method 'FS'This database file locking mechanism uses native file system lock on the database file. No *.lock.db file is created in this case, and no background thread is started. This mechanism may not work on all systems as expected. Some systems allow to lock the same file multiple times within the same virtual machine, and on some system native file locking is not supported or files are not unlocked after a power failure.
To enable this feature, append This feature is relatively new. When using it for production, please ensure your system does in fact lock files as expected. File Locking Method 'Serialized'This locking mode allows to open multiple connections to the same database. The connections may be opened from multiple processes and from different computers. When writing to the database, access is automatically synchronized internally. Write operations are slower than when using the server mode, and concurrency is relatively poor. The advantage of this mode is that there is no need to start a server.
To enable this feature, append This feature is relatively new. When using it for production, please ensure your use case is well tested (if possible with automated test cases). Using PasswordsUsing Secure PasswordsRemember that weak passwords can be broken regardless of the encryption and security protocols. Don't use passwords that can be found in a dictionary. Appending numbers does not make passwords secure. A way to create good passwords that can be remembered is: take the first letters of a sentence, use upper and lower case characters, and creatively include special characters (but it's more important to use a long password than to use special characters). Example:
Passwords: Using Char Arrays instead of StringsJava strings are immutable objects and cannot be safely 'destroyed' by the application. After creating a string, it will remain in the main memory of the computer at least until it is garbage collected. The garbage collection cannot be controlled by the application, and even if it is garbage collected the data may still remain in memory. It might also be possible that the part of memory containing the password is swapped to disk (if not enough main memory is available), which is a problem if the attacker has access to the swap file of the operating system. It is a good idea to use char arrays instead of strings for passwords. Char arrays can be cleared (filled with zeros) after use, and therefore the password will not be stored in the swap file. This database supports using char arrays instead of string to pass user and file passwords. The following code can be used to do that:
import java.sql.*;
import java.util.*;
public class Test {
public static void main(String[] args) throws Exception {
Class.forName("org.h2.Driver");
String url = "jdbc:h2:~/test";
Properties prop = new Properties();
prop.setProperty("user", "sa");
System.out.print("Password?");
char[] password = System.console().readPassword();
prop.put("password", password);
Connection conn = null;
try {
conn = DriverManager.getConnection(url, prop);
} finally {
Arrays.fill(password, (char) 0);
}
conn.close();
}
}
This example requires Java 1.6.
When using Swing, use Passing the User Name and/or Password in the URL
Instead of passing the user name as a separate parameter as in
Password Hash
Sometimes the database password needs to be stored in a configuration file
(for example in the
To connect using the password hash instead of plain text password, append
Protection against SQL InjectionWhat is SQL InjectionThis database engine provides a solution for the security vulnerability known as 'SQL Injection'. Here is a short description of what SQL injection means. Some applications build SQL statements with embedded user input such as: String sql = "SELECT * FROM USERS WHERE PASSWORD='"+pwd+"'"; ResultSet rs = conn.createStatement().executeQuery(sql);
If this mechanism is used anywhere in the application, and user input is not correctly filtered or encoded,
it is possible for a user to inject SQL functionality or statements by using specially built input
such as (in this example) this password: SELECT * FROM USERS WHERE PASSWORD='' OR ''=''; Which is always true no matter what the password stored in the database is. For more information about SQL Injection, see Glossary and Links. Disabling LiteralsSQL Injection is not possible if user input is not directly embedded in SQL statements. A simple solution for the problem above is to use a prepared statement: String sql = "SELECT * FROM USERS WHERE PASSWORD=?"; PreparedStatement prep = conn.prepareStatement(sql); prep.setString(1, pwd); ResultSet rs = prep.executeQuery(); This database provides a way to enforce usage of parameters when passing user input to the database. This is done by disabling embedded literals in SQL statements. To do this, execute the statement: SET ALLOW_LITERALS NONE;
Afterwards, SQL statements with text and number literals are not allowed any more.
That means, SQL statement of the form Using Constants
Disabling literals also means disabling hard-coded 'constant' literals. This database supports
defining constants using the CREATE SCHEMA CONST AUTHORIZATION SA; CREATE CONSTANT CONST.ACTIVE VALUE 'Active'; CREATE CONSTANT CONST.INACTIVE VALUE 'Inactive'; SELECT * FROM USERS WHERE TYPE=CONST.ACTIVE; Even when literals are enabled, it is better to use constants instead of hard-coded number or text literals in queries or views. With constants, typos are found at compile time, the source code is easier to understand and change. Using the ZERO() Function
It is not required to create a constant for the number 0 as there is already a built-in function SELECT * FROM USERS WHERE LENGTH(PASSWORD)=ZERO(); Protection against Remote Access
By default this database does not allow connections from other machines when starting the H2 Console,
the TCP server, or the PG server. Remote access can be enabled using the command line
options Restricting Class Loading and Usage
By default there is no restriction on loading classes and executing Java code for admins.
That means an admin may call system functions such as
CREATE ALIAS SET_PROPERTY FOR "java.lang.System.setProperty";
CALL SET_PROPERTY('abc', '1');
CREATE ALIAS GET_PROPERTY FOR "java.lang.System.getProperty";
CALL GET_PROPERTY('abc');
To restrict users (including admins) from loading classes and executing code,
the list of allowed classes can be set in the system property
java -Dh2.allowedClasses=java.lang.Math,com.acme.* This mechanism is used for all user classes, including database event listeners, trigger classes, user-defined functions, user-defined aggregate functions, and JDBC driver classes (with the exception of the H2 driver) when using the H2 Console. Security ProtocolsThe following paragraphs document the security protocols used in this database. These descriptions are very technical and only intended for security experts that already know the underlying security primitives. User Password EncryptionWhen a user tries to connect to a database, the combination of user name, @, and password are hashed using SHA-256, and this hash value is transmitted to the database. This step does not protect against an attacker that re-uses the value if he is able to listen to the (unencrypted) transmission between the client and the server. But, the passwords are never transmitted as plain text, even when using an unencrypted connection between client and server. That means if a user reuses the same password for different things, this password is still protected up to some point. See also 'RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication' for more information. When a new database or user is created, a new random salt value is generated. The size of the salt is 64 bits. Using the random salt reduces the risk of an attacker pre-calculating hash values for many different (commonly used) passwords. The combination of user-password hash value (see above) and salt is hashed using SHA-256. The resulting value is stored in the database. When a user tries to connect to the database, the database combines user-password hash value with the stored salt value and calculates the hash value. Other products use multiple iterations (hash the hash value again and again), but this is not done in this product to reduce the risk of denial of service attacks (where the attacker tries to connect with bogus passwords, and the server spends a lot of time calculating the hash value for each password). The reasoning is: if the attacker has access to the hashed passwords, he also has access to the data in plain text, and therefore does not need the password any more. If the data is protected by storing it on another computer and only accessible remotely, then the iteration count is not required at all. File EncryptionThe database files can be encrypted using two different algorithms: AES-128 and XTEA (using 32 rounds). The reasons for supporting XTEA is performance (XTEA is a bit faster as AES in some environments) and to have an alternative algorithm if AES is suddenly broken. Please note that the XTEA implementation used in this database only uses 32 rounds and not 64 rounds as recommended by its inventor (as of 2010, the best known attack is on 27 rounds).
When a user tries to connect to an encrypted database, the combination of
When a new database file is created, a new cryptographically secure random salt value is generated. The size of the salt is 64 bits. The combination of the file password hash and the salt value is hashed 1024 times using SHA-256. The reason for the iteration is to make it harder for an attacker to calculate hash values for common passwords. The resulting hash value is used as the key for the block cipher algorithm (AES-128 or XTEA with 32 rounds). Then, an initialization vector (IV) key is calculated by hashing the key again using SHA-256. This is to make sure the IV is unknown to the attacker. The reason for using a secret IV is to protect against watermark attacks. Before saving a block of data (each block is 8 bytes long), the following operations are executed: first, the IV is calculated by encrypting the block number with the IV key (using the same block cipher algorithm). This IV is combined with the plain text using XOR. The resulting data is encrypted using the AES-128 or XTEA algorithm. When decrypting, the operation is done in reverse. First, the block is decrypted using the key, and then the IV is calculated combined with the decrypted text using XOR. Therefore, the block cipher mode of operation is CBC (cipher-block chaining), but each chain is only one block long. The advantage over the ECB (electronic codebook) mode is that patterns in the data are not revealed, and the advantage over multi block CBC is that flipped cipher text bits are not propagated to flipped plaintext bits in the next block. Database encryption is meant for securing the database while it is not in use (stolen laptop and so on). It is not meant for cases where the attacker has access to files while the database is in use. When he has write access, he can for example replace pieces of files with pieces of older versions and manipulate data like this. File encryption slows down the performance of the database engine. Compared to unencrypted mode, database operations take about 2.2 times longer when using XTEA, and 2.5 times longer using AES (embedded mode). Wrong Password / User Name Delay
To protect against remote brute force password attacks, the delay after each unsuccessful
login gets double as long. Use the system properties There is only one exception message for both wrong user and for wrong password, to make it harder to get the list of user names. It is not possible from the stack trace to see if the user name was wrong or the password. HTTPS Connections
The web server supports HTTP and HTTPS connections using SSL/TLS Connections
Remote SSL/TLS connections are supported using the Java Secure Socket Extension
(
To use your own keystore, set the system properties
To disable anonymous SSL, set the system property Universally Unique Identifiers (UUID)
This database supports UUIDs. Also supported is a function to create new UUIDs using
a cryptographically strong pseudo random number generator.
With random UUIDs, the chance of two having the same value can be calculated
using the probability theory. See also 'Birthday Paradox'.
Standardized randomly generated UUIDs have 122 random bits.
4 bits are used for the version (Randomly generated UUID), and 2 bits for the variant (Leach-Salz).
This database supports generating such UUIDs using the built-in function
public class Test {
public static void main(String[] args) throws Exception {
double x = Math.pow(2, 122);
for (int i = 35; i < 62; i++) {
double n = Math.pow(2, i);
double p = 1 - Math.exp(-(n * n) / 2 / x);
System.out.println("2^" + i + "=" + (1L << i) +
" probability: 0" +
String.valueOf(1 + p).substring(1));
}
}
}
Some values are:
To help non-mathematicians understand what those numbers mean, here a comparison: one's annual risk of being hit by a meteorite is estimated to be one chance in 17 billion, that means the probability is about 0.000'000'000'06. Recursive QueriesH2 has experimental support for recursive queries using so called "common table expressions" (CTE). Examples:
WITH RECURSIVE T(N) AS (
SELECT 1
UNION ALL
SELECT N+1 FROM T WHERE N<10
)
SELECT * FROM T;
-- returns the values 1 .. 10
WITH RECURSIVE T(N) AS (
SELECT 1
UNION ALL
SELECT N*2 FROM T WHERE N<10
)
SELECT * FROM T;
-- returns the values 1, 2, 4, 8, 16
CREATE TABLE FOLDER(ID INT PRIMARY KEY, NAME VARCHAR(255), PARENT INT);
INSERT INTO FOLDER VALUES(1, null, null), (2, 'src', 1),
(3, 'main', 2), (4, 'org', 3), (5, 'test', 2);
WITH LINK(ID, NAME, LEVEL) AS (
SELECT ID, NAME, 0 FROM FOLDER WHERE PARENT IS NULL
UNION ALL
SELECT FOLDER.ID, IFNULL(LINK.NAME || '/', '') || FOLDER.NAME, LEVEL + 1
FROM LINK INNER JOIN FOLDER ON LINK.ID = FOLDER.PARENT
)
SELECT NAME FROM LINK WHERE NAME IS NOT NULL ORDER BY ID;
-- src
-- src/main
-- src/main/org
-- src/test
Limitations: Recursive queries need to be of the type
WITH RECURSIVE recursiveQueryName(columnName, ...) AS (
nonRecursiveSelect
UNION ALL
recursiveSelect
)
select
Settings Read from System Properties
Some settings of the database can be set on the command line using
java -Dh2.serverCachedObjects=256 org.h2.tools.Server
The current value of the settings can be read in the table
For a complete list of settings, see SysProperties. Setting the Server Bind Address
Usually server sockets accept connections on any/all local addresses.
This may be a problem on multi-homed hosts.
To bind only to one address, use the system property Pluggable File SystemThis database supports a pluggable file system API. The file system implementation is selected using a file name prefix. The following file systems are included:
As an example, to use the the
To register a new file system, extend the classes Database UpgradeIn version 1.2, H2 introduced a new file store implementation which is incompatible to the one used in versions < 1.2. To automatically convert databases to the new file store, it is necessary to include an additional jar file. The file can be found at http://h2database.com/h2mig_pagestore_addon.jar . If this file is in the classpath, every connect to an older database will result in a conversion process.
The conversion itself is done internally via
Since version 1.2.140 it is possible to let the old h2 classes (v 1.2.128) connect to the database.
The automatic upgrade .jar file must be present, and the URL must start with Limits and LimitationsThis database has the following known limitations:
Glossary and Links
|