How to use Deephaven in a local development environment
Set up your IDE
Note
Download Example project files
This example will use IntelliJ IDEA together with the Gradle build tool and show you how to:
- Create a new Gradle project.
- Add Groovy if you plan to use it to create queries.

Your new project will include a build.gradle file that looks something like this:
To add Deephaven libraries to your project, add the following to your dependencies:
This will add the DB module (which includes helpful classes like Table or Database) and configs module
(which includes configuration files with default property values) to your project.
To download all Deephaven modules, use 'iris:Iris:' + version.
Next, add the following Maven repository with your credentials. artifactoryUser and artifactoryAPIKey
must be set in gradle.properties:
Your build.gradle file will now look something like:
Refresh the project, and Gradle will download the specified modules.

Local unit testing
It may be helpful to have some local test data you can use to test your query's correctness.
The following example requires the DB and fishlib modules.
The following simple query calculates the average prices of stocks for a given day:
It uses a helper method which is written in Java so that it can be unit tested:
We need a local copy of the Example.StockTrades schema:
And some test data (saved as src/test/resources/StockTrades.csv in the example project):
- The first step to load the schema and test data into the database is to create a
Configurationobject. TheConfigurationcontains the JVM options, several of which are required to create aDatabase. This example uses thebuild.gradlefile from before to set unit test configurations.
| Property | Description |
|---|---|
Configuration.rootFile | The base property file. |
devroot | Contains all jar and configuration files. |
workspace | Will be the root of the local Deephaven file structure. The example unit test will store the table data here. |
com.fishlib.configuration.PropertyInputStreamLoader.override | Set to PropertyInputStreamLoaderTraditional. This loads property files from the classpath, as opposed to, for example, etcd. |
See Client Configuration for more information on the Configuration.
- Next, you will need to create a local
SchemaServiceinstance.
The SchemaService will load all schema files inside the schemaDir directory.

Caution
The Groovy query is purposefully stored in src/main/resources instead of src/main/groovy to ensure it is not compiled.
The example query script is intended to run in a Groovy session inside a Deephaven query worker, which contains
additional predefined variables (such as db) and imported classes that are not available during compilation in the
local development environment.
- Create the
OnDiskQueryDatabase:
- Start the
OnDiskQueryDatabaseand set a user context:
- Add the test data:
- Use the table getter methods described in the Ultimate Cheat Sheet to test your query:
The full test class:
Connect to a remote DB
Client applications can connect to Deephaven server installations to run queries on a remote database.
The application must be configured to use the program files downloaded by the Deephaven Launcher. Below is an example VM configuration on a Mac:
Note
- See How to connect to Deephaven from another Java program for more information on these configuration options and for how to set up the private key for authentication.
- See Client Configuration for more information about
dh.config.client.bootstrap.
Inside the application, the first step will be to create a RemoteQueryClient and push the required
classes. This makes it so that the remote server can use your local classes. We use the same QueryUtils as before
in this example.
The RemoteQueryClient is then used to create the RemoteDatabase.
The RemoteDatabase may be queried with ad-hoc method calls (db.i, db.t, etc.), comparable to the db variable in a Deephaven
Console. Because the methods are being called against the RemoteDatabase locally in the client application, each
operation requires a round-trip between the client and the worker. For infrequent or very ad-hoc use, this may be fine;
for applications where a query will be executed repeatedly, better performance can be achieved by using a
ContextAwareRemoteQuery object to allow the method calls to be made as part of a single execution call from the client
to the worker.