Configuration file

DBMonster uses simple property configuration file. It contains JDBC connection description as well as some other options. DBMonster looks for the configuration options in three places (in that order, last definition wins):

  • dbmonster.properties located in user's home,
  • dbmonster.properties located in current dir,
  • a file supplied by user (-c command line switch).
Sample configuration file: 

dbmonster.jdbc.driver=org.postgresql.Driver
dbmonster.jdbc.url=jdbc:postgresql://127.0.0.1/dbmonster?charSet=iso-8859-2
dbmonster.jdbc.username=dbmonster
dbmonster.jdbc.password=dbmonster
dbmonster.jdbc.transaction.size=50

# for Oracle and other schema enabled databases
dbmonster.jdbc.schema=schema_name

# maximal number of (re)tries
dbmonster.max-tries=1000

# default rows number for SchemaGrabber
dbmonster.rows=1000

# progres monitor class
dbmonster.progress.monitor=pl.kernelpanic.dbmonster.ProgressMonitorAdapter

dbMonster uses sort of brute-force method to put the tuples into the database (for speed reason). There is an risk that chosen data generator is not able to produce enough unique values for unique indices. Using max-tries element you may configure how many times dbMonster should try to regenerate values after failure of insertion. After that dbMonster gives up. This is per-table limit.
dbMonster's schema files are case sensitive. Period.

Schema mapping file

The schema file describes the look of the tables. You may divide a large database schema into several separate smaller schema files if you like. 

dbmonster-schema.xml - sample schema file
       
<?xml version="1.0" encoding="iso-8859-1"?>

<!DOCTYPE dbmonster-schema PUBLIC 
    "-//kernelpanic.pl//DBMonster Database Schema DTD 1.1//EN"
    "http://dbmonster.kernelpanic.pl/dtd/dbmonster-schema-1.1.dtd">
    
<dbmonster-schema>
   <name>Test Schema</name>
    <table name="table01" rows="1500">
        <key databaseDefault="false">
           <generator type="pl.kernelpanic.dbmonster.generator.MaxKeyGenerator">
               <property name="columnName" value="id"/>
           </generator>
        </key>
        <column name="login">
            <generator type="pl.kernelpanic.dbmonster.generator.StringGenerator">
                <property name="nulls" value="0"/>
                <property name="minLength" value="4"/>
                <property name="maxLength" value="12"/>
                <property name="allowSpaces" value="false"/>
            </generator>
        </column>
    </table>
    <table name="table02" rows="2500">
        <key databaseDefault="false">
           <generator type="pl.kernelpanic.dbmonster.generator.StringKeyGenerator">
               <property name="columnName" value="id"/>
               <!-- if start value is set to 0 (zero)
                       start value is grabbed from database
                       using select max(columnName) from table -->
               <property name="startValue" value="aaaaaaaa"/>
           </generator>
        </key>
    </table>
</dbmonster-schema>

The databaseDefault attribute of columns and keys is used to control whether the column/key value is generated by dbMonster. If set to "false", a value is generated for the column/key, if set to "true" a value is not generated for the column/key. Some databases support the definition of default values for a specific column. This is typically implemented using either database constraints or database triggers. If your database supports default values, setting databaseDefault to "true" will allow the default value to be generated by the database and not by dbMonster.The databaseDefault attribute of columns and keys is used to control whether the column/key value is generated by dbMonster. If set to "false", a value is generated for the column/key, if set to "true" a value is not generated for the column/key. Some databases support the definition of default values for a specific column. This is typically implemented using either database constraints or database triggers. If your database supports default values, setting databaseDefault to "true" will allow the default value to be generated by the database and not by dbMonster.

Pre- and post script execution

Optionally you can specify the SQL scripts which dbMonster should execute before and after data generation. Use -f and -l command line options to achieve this. Both takes a file path as an argument. The script must contain _one query per line_.

Running DBMonster

Linux and friends:

  1. cd to dbMonster's instalation directory,
  2. copy all jars you need to lib directory,
  3. adjust log4j.properties file so it fits your needs,
  4. chmod +x bin/dbmonster
  5. ./bin/dbmonster -h
  6. Run dbMonster and have fun!

Windows:

  1. cd to the "bin" directory in dbMonster's instalation directory,
  2. copy all jars you need to ..\lib directory,
  3. adjust log4j.properties file so it fits your needs,
  4. type: dbmonster.bat (batch file contributed by Peter De Bruycker, thanks!)
  5. Run dbMonster and have fun!

All platforms - it is not recomended because JVM silently ignores the -classpath argument:
cd to dbmonster's installation directory and type: 

java -jar dbmonster-VERSION.jar -s path/to/schemas/*.xml \
     -c dbmonster.properties

To run Schema Grabber type: 

# grab all tables and set output to STDOUT
java -jar dbmonster-VERSION.jar -c dbmonster.properties --grab

# grab all tables and set output to STDOUT, use provided properies
java -Ddbmonster.jdbc.driver=org.postgresql.Driver \
     -Ddbmonster.jdbc.url=jdbc:postgresql://127.0.0.1/dbmonster \
     -Ddbmonster.jdbc.username=dbmonster \
     -Ddbmonster.jdbc.password=dbmonster \
     -jar dbmonster-VERSION.jar --grab

# grab some tables and set output to specific file
java -jar dbmonster-VERSION.jar --grab -t table1 table2 -o /tmp/schema.xml

For help and list of command line options type: 

java -jar dbmonster-VERSION.jar --help