Kodo JDO can take advantage of any JDBC 1.x compliant driver, making almost any major database a candidate for use. See our officially supported database list for more information. Typically, Kodo JDO auto-configures its JDBC behavior and SQL for your database, based on the values of your connection-related JDO configuration properties.
If Kodo JDO cannot detect what type of database you are using, or if you are using an unsupported database, you will have to tell Kodo JDO what kodo.jdbc.sql.DBDictionary to use. The DBDictionary abstracts away the differences between databases. You can plug a dictionary into Kodo JDO using the kodo.jdbc.DBDictionary configuration property. The built-in dictionaries are listed below. If you are using an unsupported database, you may have to write your own DBDictionary subclass, a simple process.
access: Dictionary for Microsoft Access. This is an alias for the kodo.jdbc.sql.AccessDictionary class.
db2: Dictionary for IBM's DB2 database. This is an alias for the kodo.jdbc.sql.DB2Dictionary class.
derby: Dictionary for the Apache Derby database. This is an alias for the kodo.jdbc.sql.DerbyDictionary class.
empress: Dictionary for Empress database This is an alias for the kodo.jdbc.sql.EmpressDictionary class.
foxpro: Dictionary for Microsoft Viual FoxPro. This is an alias for the kodo.jdbc.sql.FoxProDictionary class.
hsql: Dictionary for the Hypersonic SQL database. This is an alias for the kodo.jdbc.sql.HSQLDictionary class.
informix: Dictionary for the Informix database. This is an alias for the kodo.jdbc.sql.InformixDictionary class.
jdatastore: Dictionary for Borland JDataStore. This is an alias for the kodo.jdbc.sql.JDataStoreDictionary class.
mysql: Dictionary for the MySQL database. This is an alias for the kodo.jdbc.sql.MySQLDictionary class.
oracle: Dictionary for Oracle. This is an alias for the kodo.jdbc.sql.OracleDictionary class.
pointbase: Dictionary for Pointbase Embedded database. This is an alias for the kodo.jdbc.sql.PointbaseDictionary class.
postgres: Dictionary for PostgreSQL. This is an alias for the kodo.jdbc.sql.PostgresDictionary class.
sqlserver: Dictionary for Microsoft's SQLServer database. This is an alias for the kodo.jdbc.sql.SQLServerDictionary class.
sybase: Dictionary for Sybase. This is an alias for the kodo.jdbc.sql.SybaseDictionary class.
The standard dictionaries all recognize the following properties. These properties will usually not need to be overridden, since the dictionary implementation should use the appropriate default values for your database. Typically these properties will only be changed when designing your own DBDictionary for an unsupported database.
DriverVendor: The vendor of the particular JDBC driver you are using. Some dictionaries must alter their behavior depending on the driver vendor. See the VENDOR_XXX constants defined in your dictionary's Javadoc for available options.
ConstraintNameMode: When creating constraints, whether to put the constraint name before the definition (before), just after the constraint type name (mid), or after the constraint definition (after). Defaults to before.
traditional: Traditional SQL join syntax; outer joins are not supported.
database: The database's native join syntax. Databases that do not have a native syntax will default to one of the other options.
sql92: ANSI SQL92 join syntax. Outer joins are supported. Not all databases support this syntax.
RequiresConditionForCrossJoin: Some databases require that there always be a conditional statement for a cross join. If set, this parameter ensures that there will always be some condition to the join clause.
DistinctCountColumnSeparator: The string the database uses to delimit between column expressions in a SELECT COUNT(DISTINCT column-list) clause. Defaults to null for most databases, meaning that multiple columns in a distinct COUNT clause are not supported.
SimulateLocking: Some databases do not support pessimistic locking, which will result in a JDOException when a pessimistic transaction is attempted. Setting this property to true will bypass the locking check to allow pessimistic transactions even on databases that do not support locking. Defaults to false.
BatchParameterLimit: The maximum number of total parameters that can be batched together for a single batch update. Some databases can only handle a certain total number of prepared statement parameters in a single batch. This value will cause Kodo to flush a SQL batch once the number of batched statements times the number of bound parameters per statement exceeds this value. Set to 0 to disable SQL batching, or -1 for no limit.
StorageLimitationsFatal: If true, then any data truncation/rounding that is performed by the dictionary in order to store a value in the database will be treated as a fatal error, rather than just issuing a warning.
StoreLargeNumbersAsStrings: Many databases have limitations on the number of digits that can be stored in a numeric field (for example, Oracle can only store 38 digits). For applications that operate on very large BigInteger and BigDecimal values, it may be necessary to store these objects as string fields rather than the database's numeric type. Note that this may prevent meaningful numeric queries from being executed against the database. Defaults to false.
TableTypes: Comma-separated list of table types to use when looking for tables during schema reflection, as defined in the java.sql.DatabaseMetaData.getTableInfo JDBC method. An example is: "TABLE,VIEW,ALIAS". Defaults to "TABLE".
SupportsNullTableForGetColumns: If true, then the database supports passing a null parameter to DatabaseMetaData.getColumns as an optimization to get information about all the tables. Defaults to true.
SupportsNullTableForGetPrimaryKeys: If true, then the database supports passing a null parameter to DatabaseMetaData.getPrimaryKeys as an optimization to get information about all the tables. Defaults to false.
SupportsNullTableForGetIndexInfo: If true, then the database supports passing a null parameter to DatabaseMetaData.getIndexInfo as an optimization to get information about all the tables. Defaults to false.
SupportsNullTableForGetImportedKeys: If true, then the database supports passing a null parameter to DatabaseMetaData.getImportedKeys as an optimization to get information about all the tables. Defaults to false.
UseGetBestRowIdentifierForPrimaryKeys: If true, then metadata queries will use DatabaseMetaData.getBestRowIdentifier to obtain information about primary keys, rather than DatabaseMetaData.getPrimaryKeys.
AutoIncrementClause: The column defintion clause to append to a creation statement. For example, "AUTO_INCREMENT" for MySQL. This property is set automatically in the dictionary, and should not need to be overridden, and is only used when the schema is generated using the mappingtool.
AutoIncrementTypeName: The column type name for auto-increment columns. For example, "SERIAL" for PostgreSQL. This property is set automatically in the dictionary, and should not need to be overridden, and is only used when the schema is generated using the mappingtool.
LastGeneratedKeyQuery: The query to issue to obtain the last automatically generated key for an auto-increment column. For example, "select @@identity" for Sybase. This property is set automatically in the dictionary, and should not need to be overridden.
The mysql dictionary also understands the following properties:
DriverDeserializesBlobs: Many MySQL drivers automatically deserialize BLOBs on calls to ResultSet.getObject. The MySQLDictionary overrides the standard DBDictionary.getBlobObject method to take this into account. If your driver does not deserialize automatically, set this property to false.
The oracle dictionary understands the following properties:
UseTriggersForAutoIncrement: If true, then Kodo will allow simulation of auto-increment columns by the use of Oracle triggers. Kodo will assume that the current sequence value from the sequence specified in the AutoIncrementSequenceName parameter will hold the value of the new primary key for rows that have been inserted. For more details on auto-increment support, see Section 220.127.116.11, “Auto-Increment”.
AutoIncrementSequenceName: The global name of the sequence that Kodo will assume to hold the value of primary key value for rows that use auto-increment. If left unset, Kodo will use a the sequence named "SEQ_<table name>".
MaxEmbeddedBlobSize: Oracle is unable to persist Blobs using the embedded update method when Blobs get over a certain size. The size depends on database configuration, e.g. encoding. This property defines the maximum size Blob to persist with the embedded method. Defaults to 4000 bytes.
MaxEmbeddedClobSize: Oracle is unable to persist Clobs using the embedded update method when Clobs get over a certain size. The size depends on database configuration, e.g. encoding. This property defines the maximum size Clob to persist with the embedded method. Defaults to 4000 characters.