The following represents a list of significant known bugs and limitations of Kodo JDO. These features were not ready in time for this release, but are expected to be added to future releases:
Non-static inner classes cannot be persisted.
Static fields cannot be persisted.
Fields of an unknown type (i.e. java.lang.Object) or a user-defined type that is not persistence-capable must be serializable.
Fields of type Locale are persisted through serialization only.
Persistent fields of any Map type must use simple key classes (i.e. String, Integer, Boolean, etc) or will be persisted through serialization only.
Queries do not support the ~ operator.
Queries do not support the - operator used for unary negation (it can be used for subtraction and to represent negative numbers).
If a query ordering that traverses a relation is used, but that relation is not traversed in the filter, then no join will be performed and the resultant collection will therefore be incorrect.
Queries do not support declared variables that are not bound in a contains(), containsKey(), or containsValue() clause.
Fields persisted through serialization cannot be used in queries.
Using a cast in a Query made against an Extent may not prevent instances of the base class from being returned.
The SchemaTool does not detect secondary tables that are no longer used.
Kodo JDO Enterprise Edition does not support redeployment of EJBs.
Queries that use parameters for matching fields whose underlying data store type is CLOB (string fields with column-length set to -1) cannot be compiled.
Queries that use parameters as values in startsWith() or endsWith() calls must manually concatenate a % to the parameter passed to execute()
Additionally, the following database and JVM specific limitations exist:
Sun JDK 1.2.2 on Solaris
There seem to be bytecode-level incompatibilities between Kodo and Sun's 1.2.2 JDKs for Solaris. Sun's 1.3 JDKs for Solaris, however, work without problems. This issue is being investigated.
InstantDB
Pessimistic locking is not supported.
Using isEmpty() in queries made against an Extent will fail because SQL sub-selects are not supported.
MySQL
Using isEmpty() in queries made against an Extent will fail because SQL sub-selects are not supported.
Rollback due to database error or optimistic lock violation is not supported unless the table type is one of the MySQL transactional types. Explicit calls to rollback() before a transaction has been committed, however, are always supported.
Floats and doubles may lose precision when stored in some data stores.
When storing a field of type java.math.BigDecimal, some data stores will add extraneous trailing 0 characters, causing an equality mismatch between the field that is stored and the field that is retrieved.
PostgreSQL
Pessimistic locking is not supported on queries that use SELECT DISTINCT (i.e. any query that uses contains(), containsValue(), or containsKey()). Modifying objects found using such queries in pessimistic transactions is permitted but may result in an optimistic lock exception if the same instances are also modified by another concurrent thread.
Floats and doubles may lose precision when stored.
PostgreSQL cannot store very low and very high Dates.
Empty string/char values are stored as NULL.
BLOBs are not supported; fields cannot be stored via serialization.
IBM DB2
Floats and doubles may lose precision when stored.
Empty char values are stored as NULL.
Pessismistic locking is not supported.
Fields of type BLOB and CLOB are limited to 1M. This number can be increased by extending DB2Dictionary
Oracle
Pessimistic locking is not supported on queries that use SELECT DISTINCT (i.e. any query that uses contains(), containsValue(), or containsKey()). Modifying objects found using such queries in pessimistic transactions is permitted but may result in an optimistic lock exception if the same instances are also modified by another concurrent thread.
Floats and doubles may lose precision when stored.
CLOB columns cannot be used in queries.
SQLServer
Floats and doubles may lose precision when stored.
TEXT columns cannot be used in queries.
Sybase
Datastore locking cannot be used when manipulating many-to-many relations using the default Kodo schema created by the schematool, unless an auto-increment primary key field is manually added to the table.
PointBase
Fields of type BLOB and CLOB are limited to 1M. This number can be increased by extending PointbaseDictionary
Please see the Kodo JDO bug tracking database for an up-to-date bug list.