4.0.1 - ???

• Bugfixes

  • Fixed a NullPointerException from the enhancer when a property access entity has a non-trivial getter method and is missing a setter method.

4.0.0 - May 14, 2006

• New features

  Kodo 4 is a major release. Its primary new features are support for the Java Persistence API and Java Data Objects atop a shared persistence kernel, and a new mapping system to ease the creation of custom mappings. However, Kodo 4 includes a host of other improvements as well. See the documentation for details.

• Notable Changes

  • Major changes to internal APIs, package structure, mapping format, and configuration options. See Section 6.4, “Migrating from Kodo 3.x to Kodo 4.0” for backwards-compatibility options.

  • The Oracle dictionary will now automatically test the batching capabilities of the JDBC driver when it first connects and enable or disable batching support as a result of the test. See See the TestBatchSupport parameter description.

  • The included Hypersonic database has been upgraded from version 1.7.0 to 1.8.0.

  • The supported version of Apache Derby is now upgraded to the non-alpha release 10.1.1.0. See Section 4.1, “Apache Derby”.

  • Calling makeTransactional on an instance will now force a version check for the instance at commit time, even if the instance hasn't changed during the transaction.

  • The official supported version of the Microsoft SQLServer driver is now 1.0.809.102.

  • The official supported version of the Oracle JDBC driver is now 10.2.0.1.0.

3.4.0 - November 8, 2005

• New features

  • Added a new Section 2.7.40, “kodo.ManagedRuntime” option for improved integration with BEA WebLogic Server. It is used by default when using WLS.

  • Added the AttachFetchFields parameter of the kodo.PersistenceManagerImpl property to enable the automatic addition of detach fields to the current fetch configuration. See Section 11.1.3, “Defining the Detached Object Graph”.

  • Query cache now caches aggregates and projections, including queries that use grouping. Query cache also caches queries that compare single-valued fields to persistence-capable parameters (such as select from Employee where address == :addr).

  • Added support for savepoints, with both in-memory and JDBC 3 plugins. Note that some drivers / database combinations do not support JDBC 3 or savepoints. For more details, see Section 9.5, “Savepoints”

  • Added support for Oracle Object fields through JDBC SQLData interfaces.

  • JDODataStoreExceptions will now contain the failed persistent instance in the getFailedObject whenever possible. Enhancement #1183.

  • When attaching multiple instances, object lookups will be batched together the make the process of merging in multiple instances more efficient.

  • SQLWarning instances are now checked and can be handled in a customizable way. The WarningAction parameter of the kodo.ConnectionFactoryProperties property can be used to control this.

  • Parameters to PreparedStatements will now be tracked so that they can be included in error messages if the statement fails. The TrackParameters parameter of the kodo.ConnectionFactoryProperties property can be used to control this.

  • The PropertiesReverseCustomizer will now log messages to the TRACE level of the Metadata channel reporting whether or not a custom name was found for each class and field name that is reverse mapped.

  • It is now possible the specify the default SQL type name mapping to java types with the typeMap argument to the reverse mapping tool. See Section 7.2, “Reverse Mapping”.

  • Kodo JDO Enterprise Edition and the Kodo JDO Performance Pack now include a query cache plug-in that uses Tangosol Coherence cache products. See the data cache integration documentation for more information regarding caching. If you make use of Tangosol for both your query and datacache you no longer need to specify a remote commit provider.

  • Kodo now logs its runtime configuration to the kodo.Runtime channel at TRACE level when the PersistenceManagerFactory initializes.

  • Added the UseSetFormOfUseForUnicode parameter to the DBDictionary for Oracle, which enables Kodo to perform special configuration for unicode fields required for Oracle versions prior to 10i. See OracleDictionary.UseSetFormOfUseForUnicode.

  • Kodo management capability now supported in JBoss 4.

• Notable Changes

  • Added ability for SQLServerDictionary to treat UNIQUEIDENTIFIER as either String or byte[] data.

  • Official Oracle JDBC driver support has been upgraded from 9.0.1.0.0 to 10.1.0.4. See Appendix 4, Supported Databases.

  • Kodo now determines whether or not an externalized field should be part of the default fetch group based on the type that the field is externalized to, rather than the actual field type. This means that fields of unknown type (which would normally be excluded from the default fetch group by default) will be included in the initial fetching if they are externalized to a primimtive type that Kodo understands natively.

  • Eager query result lists now remain open after the PersistenceManager has closed.

  • Attempts to enhance JDK1.5 enum types will result in an error at enhancement time, rather than deferred unexpected behavior later in execution. Kodo does support fields of type enum in managed instances, but not managed enums themselves.

• Bugfixes

  • A bug with queries involving quoted numbers has been fixed. In Kodo 3.1 and prior, the first digit of a single-quoted character literal of any length was treated as a character constant, and double-quoted numbers were treated as unquoted numeric constants. Kodo 3.2 and 3.3 were undeterministic regarding the handling of numeric comparisons to single- and double-quoted literals. By default, Kodo 3.4 follows the JDO 2.0 rules for quoted numeric literals: double-quoted and single-quoted single-character literals are treated as character constants, and double-quoted and single-quoted multi-character literals are invalid in numeric comparisons. The old 3.1 behavior can be emulated by adding QuotedNumbersInJDOQL=3.1 to the kodo.Compatibility configuration parameter.

  • Improved application id tool to be more JDK 1.5 compatible. Changes simple static class reference into a full Class.forName call to register class in VM.

  • Positional parameters for SQL queries started at 0; now correctly start at 1 (0-based indexing is still supported).

  • Query reselut projections including null-valued one-to-one relations with queries that allow nulls will be properly retrieved.

  • The management function no longer directly references classes found only in the kodo-jdo.jar. This caused java.lang.NoClassDefFoundErrors in some configurations. Bug 1197.

3.3.4 - July 22, 2005

• Notable Changes

  • Pessimistic locks on embedded persistent types are now obtained at the same time as locks on their owning records (and vice versa), reducing the number of database roundtrips required to lock a instance and its embedded record(s).

  • Improved performance of getting PersistenceManagers when the kodo.PersistentClasses property is set.

• Bugfixes

  • The Kodo Workbench will be much faster when mounting many classes. Bug 1180.

  • The SequenceGenerator.ensureCapacity() method now uses the passed-in capacity number instead of the configured generator increment.

  • Fixed bug that cleared state of new instances that were not changed within the transaction when RestoreValues was true.

  • Removed extraneous DISTINCT from some eager fetching selects.

  • When using a third-party data source that is integrated with a JTA transaction manager, calls to KodoPersistenceManagerFactory.getPersistenceManager(boolean managed, int retainMode) will now return a PersistenceManager that uses ConnectionFactory2 instead of the primary (managed) connection factory.

  • Fixed issues with tokenization of strings in certain appidtool generated classes.

3.3.3 - May 20, 2005

• New features

  • Added DriverDeserializesBlobs property to the MySQLDictionary. Most MySQL drivers automatically deserialize BLOBs on calls to ResultSet.getObject, but some do not.

  • Kodo JDO Enterprise Edition and the Kodo JDO Performance Pack now includes a cache plug-in that supports GemStone's GemFire cache products. See the data cache integration documentation for details.

• Notable Changes

  • com.solarmetric.profile.ProfilingHelper and assorted classes were renamed to ExecutionContextNameProvider to better reflect the role that this interface plays in the Kodo profiling framework.

  • Query cache now considers parameters when calculating query key hash code (parameters were always part of equals comparisons).

• Bugfixes

  • The Kodo Workbench now correctly uses any classpath elements (such as JDBC driver jars) that you add to the Workbench when opening a query browser.

  • Fields beginning with multiple underscore characters will have all leading underscores properly trimmed. Bug 1125.

  • Fixed query caching problem with queries that involve subqueries. Bug 1122.

  • Fixed query cache interaction with certain remote commit provider configurations. Bug 1130.

  • Fixed potential exception when detaching an application identity class with embedded fields in the configured fetch groups. Bug 1142.

  • Fixed problem where in memory JDOQL queries using String.matches might match a value when it should not. Bug 1143.

  • Corrected case where using this instanceof X in a query whose candidate class is horizontally mapped would not limit the results to class X. Bug 1123.

3.3.2 - April 14, 2005

• Bugfixes

  • Fixed problem with base-horizontal-veritical hierarchy when using application identity. Bug 1114.

  • Fixed problem with ConcurrentModificationException in query cache. Bug 1115.

  • Fixed problem with ref-constant non-standard joins when using a negative number. Bug 1116.

  • Fixed problem with deadlock in datastore cache. Bug 1120.

3.3.1 - March 28, 2005

• Notable Changes

  • Throwing a JDOFatalException from a TransactionListener now propagates the exception to the user. The exception will cause a rollback if it occurs during a commit.

• Bugfixes

  • Corrected an inefficiency when performing a query against an entire hierarchy of mapped persistence-capable classes, where the candidate class extended a horizontally-mapped type.

  • Fixed problem with timestamps reporting as unknown column type on Oracle 10 with certain combination of driver and database. Bug 1111.

  • Fixed bug in new raw SQL handling abilities of Row class.

  • Fixed bug preventing Kodo from reflecting on all but the first schema-qualified table in the schemas list.

  • Corrected possible NullPointerException when committing a remote PersistenceManager transaction containing newly-persisted application identity objects in Set or Map fields.

  • Fixed bug in profiler where processing events could result in a NullPointerException.

  • Added setting UseClobs to allow for MySQL to allow clob use on versions which handle this correctly. Defaults to false for compatibility. Bug 1109.

3.3.0 - March 15, 2005

• New features

  • New KodoPersistenceManager.setPopulateDataCache method that allows transactions to control whether objects accessed during the transaction will fill the data cache. See the Javadoc.

  • New KodoPersistenceManager.setLargeTransaction method that allows transactions that act upon a large number of objects to use less memory if periodic flushes are performed. See the Javadoc.

  • Added preview support for single field identity, a JDO 2 feature. This allows for the use of application identity without writing object id classes when using a single primary key field.

  • Added lifecycle event listening framework as a JDO 2 preview feature. This currently requires importing kodo.event instead of javax.jdo.

  • Added preview support for PersistenceManager.getObjectById (Class cls, Object value). This convenience method retrieves instances based on oid, primary key value, and stringified oids.

  • Added ability to dynamically generate data structs used for datacache and remote use. Classes are dynamically created to avoid primitive wrappers, optimizing memory use and load/store performance. See the kodo.DynamicDataStructs configuration property for more details.

  • Added ability to have caches evict based on schedule. Kodo's default caches can now parse "cron" style scheduling strings to evict at granularity from minute to month. See Section 10.1.1, “Data Cache Configuration”.

  • New KodoPersistenceManager.preFlush method runs pre-flush actions such as persistence-by-reachability, deletion of dereferenced dependent objects, instance callbacks, and inverse relationship management without flushing. See the Javadoc.

  • New metadata extensions allow definition of the JDBC type or SQL type name for single column mappings (i.e. value mappings).

  • Numeric fields can now have their value assigned from the sequence generator for the owning class. This is especially useful for assigning application identity primary key values.

  • New mapping tool argument allows tool to create SQL scripts rather than XML schema files or directly acting on the database. See Section 7.1, “Forward Mapping”.

  • Kodo now works with JMX 1.2 implementations, including those that implement JSR 160. Configuration of the management capability has changed slightly. See Chapter 12, Management and Monitoring.

  • Apache Derby is now a supported database. See Section 4.1, “Apache Derby”.

  • Added support for KodoPersistenceManager.refreshAll(JDOException).

  • Enhanced JMSRemoteCommitProvider with options for passing properties to the JNDI InitialContext and for attempting to reconnect to the JMS topic if the JMS system notifies Kodo of a serious connection error. See Section 11.3.1, “Remote Commit Provider Configuration”.

  • Added ability to insert raw SQL into a given kodo.jdbc.sql.Row. This is useful for performing server side functions to generate values for custom field mappings.

  • Fields of type Collection and Map that use Java 5 generics no longer need JDO metadata specifying collection element type or map key / value types.

  • Java 5 enum field types can now be persisted natively (without the use of an externalizer). Such fields must still be listed in the JDO metadata file as persistence-modifier="persistent", as enums are not among the spec-endorsed persistent field types in JDO1. Collections of enums and maps with enum keys or values are not yet supported.

  • Kodo now provides a syntax for specifying additional lock groups in subclasses that are not used in the corresponding least-derived types. See Section 5.8.1, “Lock Groups and Subclasses” for details.

• Notable Changes

  • Sequences assigned with the db and db-class sequence factories will now ensure that the assigned sequence value is at least 1 in order to be able to distinguish between auto-assigned values and cases where the default value is 0 for a primary key field.

  • Moved and repackaged Jakarta Commons and RegExp libraries internally. This removes the dependency on the Jakarta jars as well as avoids issues with conflicting library versions. Note that to use Commons Logging plugin instead of Kodo's default one, you still need to include the Commons Logging jar in your classpath.

  • The API of Kodo's internal datastore identity type, kodo.util.Id has been aligned with JDO 2 single field identity types.

  • Simplified and enhanced the datastore cache. Standard APIs like DataCache.pin and DataCache.remove are the same, but some less-used APIs have changed. See the Javadoc for the kodo.datacache package for details.

  • Changed the handling of object id assignment. Now, PersistenceManager.getObjectId(pc) and JDOHelper.getObjectId(pc) always return the final object id of the given instance. If the instance is new and uses auto-increment columns for its identity, these methods will cause a flush so that the identity value(s) can be determined. If the instance uses application identity, you cannot change any primary key fields after retrieving the object id.

  • Removed the kodo.AutoIncrementConstraints configuration property. Kodo now determines whether it needs to perform auto increment tracking dynamically.

  • The kodo.jdbc.Schemas property is now used to limit the tables visible during runtime schema validation in addition to its traditional use to limit schema reflection in Kodo command-line tools.

  • Altered the behavior of the detach methods when the RollbackOnly flag is set to allow multiple attach/modify/detach/rollback cycles. See Section 11.1.1, “Detach Behavior” for details.

  • The Coherence datacache plug-in now performs named cache lookups using the com.tangosol.net.CacheFactory.getCache(String) method by default. This differs from earlier Kodo versions, in which the CacheFactory.getDistributedCache(String) method was used by default. This change simplifies the configuration of the integration with Coherence, and allows use of Coherence's near cache capabilities, which were not previously accessible via Kodo's out-of-the-box configuration.

  • StoreManager.newDataStoreId () signature has been changed to optimize access to non-string types.

  • Aligned single-string JDOQL with most recent version of JDO 2 draft. Kodo still supports its previous single-string grammar, but see Section 11.9, “Single-String JDOQL” for the grammar you should use going forward.

  • In support of the distributed data cache framework the TCPRemoteCommitProvider has been improved to more efficently hanlde high loads. Socket connections are pooled and reused, event messages are more compact, and properties for tuning performance (pool size and worker threads) have been added. See Section 11.3.1.2, “TCP”.

• Bugfixes

  • Added "CrossJoinClause" (???), "InnerJoinClause" (???), "OuterJoinClause" (???), and "RequiresConditionForCrossJoin" (???), in order to allow the customization of join clauses. See the description for bug #1103.

  • Made persisting many new instances in a remote persistence manager more efficient. Bug 1023.

  • In-memory queries involving java.util.Date fields work again. Bug 1057.

  • Queries involving non-managed parameters now do not have a side effect of making the parameter transactional. Bug 1061.

  • Fixed problem where kodo.rar does not deploy under JBoss 4.0. Bug 1063.

  • Fixed bug with queries using range and DISTINCT on SQLServer via changes to DBDictionary. Bug 1080.

  • Aggregate queries are no longer issued FOR UPDATE.

3.2.4 - January 6, 2005

• Bugfixes

  • Fixed bug with unique queries and query cache interaction.

  • Fixed query cache bug in which querying uncommitted changes in one transaction could cause JDOObjectNotFoundExceptions in another persistence manager.

  • Kodo can now connect to JBoss 3.2.5 via JMX.

3.2.3 - November 18, 2004

• New features

  • Added MaximizeBatchSize configuration option to default kodo.jdbc.UpdateManager property. Defaults to true, indicating that Kodo should sort statements in order to optimize batch size when statement batching is on.

• Notable Changes

  • kodo.util.ProxyCollection and kodo.util.ProxyMap no longer implement java.util.Collection and java.util.Map (respectively). This allows people to implement their own ProxyCollection in JDK 1.5 without compiler errors relating to generics.

• Bugfixes

  • Enabled ability to force no class indicator during reverse mapping process by specifying "none" as kodo.jdbc.ClassIndicator.

  • When Kodo encounters errors while processing a registered persistent type for the first time, it can now log a warning and retry the registration later instead of throwing an error. See Section 2.7.57, “kodo.RetryClassRegistration”.

3.2.2 - October 15, 2004

• New features

  • Added ability to receive a callback when Kodo discovers an orphaned database key, with built-in options for logging a message, throwing an exception, or doing nothing. See Section 7.11, “Orphaned Keys”.

  • Added ability to control JBuilder logging verbosity.

• Bugfixes

  • Fixed problem where reverse mapping the same classes twice in the Kodo Workbench would have issues when reloading the classes.

  • Fixed problem where setting the persistence-modifier of a field to "none" in the Kodo Workbench would not be preserved.

  • Prevent the connection pool from thinking that it is out of connections after repeated failed attempts to connect.

  • Fixed a bug in which conditions limiting a SELECT to certain subclasses could be left out when using final subclasses or the kodo.PersistentClasses property.

  • Fixed a bug keeping collection and map fields from being detached during detach-on-close.

  • Changed class-criteria constrained one to many fields to not null all back references when there was no inverse owner. The implicit inverse needs to be manually set to null in these cases.

3.2.1 - October 5, 2004

• Notable Changes

  • Changed the semantics of the javax.jdo.option.RestoreValues and javax.jdo.option.RetainValues properties to match JDO 1.0.1 specification. Previously, rollbacks with RestoreValues set but RetainValues unset would preserve the dirty state of the instances. They now transition to hollow. Conversely, previous rollbacks with RestoreValues unset but RetainValues set would transition the instances to hollow. They now rollback their state and transition to persistent-nontransactional.

  • Management and profiling of Kodo within WebLogic 8.1 is now supported. See Chapter 12, Management and Monitoring.

• Bugfixes

  • Fixed bug that could allow relations to get out of synch in the data cache when managed relations were enabled.

3.2.0 -- September 29, 2004

• New features

  • The reverse mapping tool interface in the workbench is now a guided wizard that allows the user to customize various aspects of the reverse mapping process.

  • The workbench will now try to compile java files into classes when the source is available but the class file is not.

  • The reverse mapping tool can now generate inner classes for application identity classes with the innerAppId option. See Section 7.2, “Reverse Mapping”.

  • Added an optional DiagnosticContext to Kodo's logging implementation. If set, all log lines from the configured PersistenceManagerFactory will be prefixed with the token. See Section 3.2, “Kodo Logging”.

  • Added support for single-string JDOQL queries, a proposed JDO 2 feature. See Section 11.9, “Single-String JDOQL”.

  • Added support for implicit JDOQL parameters and variables, a proposed JDO 2 feature. See Section 11.3, “Advanced Object Filtering”.

  • Added preview of JDO 2 named query support. See Section 11.10, “Named Queries” and Section 17.4, “Named SQL Queries”.

  • Support for subqueries in JDOQL. See Section 9.6.4, “JDOQL Subqueries”.

  • Added optional automatic management of inverse relations. See Section 5.4, “Managed Inverses”.

  • Added KodoPersistenceManager.checkConsistency to check the consistency of the persistence manager cache without enlisting additional database resources. JDO 2 preview feature.

  • Added new sample models to the samples/ directory.

  • Added ExceptionAction connection pool property to determine what to do when connections that have thrown exceptions are returned to the pool. Previous versions of Kodo always destroyed these connections, and that is still the default action. See Section 4.1, “Using the Kodo DataSource”.

  • Many improvements to the workbench, including the ability to preview the SQL DDL for classes in the workbench, the ability to print components, single-click workbench starting, the ability to dynamically edit the classpath, and many user interface tweaks.

  • Added ability to auto-externalize constant simple values (primitives, primitive wrappers and Strings) through metadata extensions. See Section 5.5.5.1, “External Values”.

  • You can now configure Kodo to detach objects with their currently-loaded fields or to detach all fields rather than detaching based on the current fetch groups. See Section 11.1.3, “Defining the Detached Object Graph”.

  • Added ability to automatically detach objects when the persistence manager closes, or when they are serialized. See Section 11.1.4, “Automatic Detachment”.

  • Vertically-mapped inheritance hierarchies no longer require a class indicator column. See Section 15.9, “Discriminator”.

  • You can now configure Kodo to outer-join to vertically mapped subclass tables when fetching data, on either a global or class-by-class basis. See Section 5.7, “Eager Fetching”.

  • Improved eager fetching. Multiple relation fields of the same type can now be eager-fetched at once. Eager fetching using parallel selects now respects large result set settings, such that the related objects are selected for each "page" of objects brought into memory. Ability to specify that certain collection fields should be eager-fetched with joins when possible, rather than with parallel selects. See Section 5.7, “Eager Fetching”.

  • Custom JDOQL extension methods can now take multiple arguments.

  • Kodo now supports InterSystems Cache. See Section 4.9, “InterSystems Cache”.

  • Added support for the javax.jdo.query.SQL query language introduced in the JDO 2 early draft specification. The kodo.jdbc.SQL query language is considered deprecated. See Chapter 17, SQL Queries for details.

  • SQL queries now support projections and custom result classes. See Section 17.3, “SQL Projections”.

  • Support for grouping and having clauses in JDOQL queries, matching JDO 2 early draft specification. See Section 11.7, “Aggregates”.

  • Support for setting result ranges on queries, matching JDO 2 early draft specification. Eager fetching works intelligently with query ranges so that the range is not affected by eager fetching and only eager data for the requested range is selected. See Section 11.5, “Limits and Ordering”.

  • As per the JDO 2 early draft specification, JDOQL now supports the following new operators and functions: instanceof, String.substring, String.indexOf, Math.abs, Math.sqrt, JDOHelper.getObjectId. See Section 11.2, “JDOQL”.

    Additionally, many JDOQL functions previously supported as Kodo query extensions are now official parts of JDOQL: String.toLowerCase, String.toUpperCase, String.matches, Map.containsKey, Map.containsValue.

  • Allow access to public static fields in JDOQL, matching JDO 2 early draft specification. See Section 11.2, “JDOQL”.

  • Allow single-quoted string literals in query filters, matching JDO 2 early draft specification. See Section 11.2, “JDOQL”.

  • Support for distinct keyword in query result string, matching JDO 2 early draft specification. See Section 11.6, “Projections”.

  • Default query result string to distinct this as C, where C is the unqualified candidate class name. Matches JDO 2 early draft specification. See Section 11.8, “Result Class”.

  • Support for setting public fields of query result classes in addition to setter methods, matching JDO 2 early draft specification. See Section 11.8, “Result Class”.

  • Added Query.Extensions map introduced in JDO 2 early draft specification.

  • Queries executed through the JDO query facilities are now logged to the kodo.Query channel. See Chapter 3, Logging.

  • Usage statistics for query results and collection and map type relations can now be viewed in the profiling tool. See Chapter 13, Profiling.

• Notable Changes

  • The KodoPersistenceManager.flush method now returns silently if no transaction is active, rather than throwing an exception. Complies with the JDO 2 early draft specification.

  • Removed the kodo.jdbc.VerticalQueryMode configuration property and associated runtime APIs. Also removed the kodo.jdbc.JoinSubclasses property and metadata extension introduced in 3.2.0b1. Use the new consolidated kodo.SubclassFetchMode property. See Section 5.7, “Eager Fetching”.

  • Upgraded Apache Commons Collections and Apache Commons Pool versions that ship with Kodo.

  • Kodo now includes the release candidate of the JDO 1.0.2 jar (jdo-1.0.2.jar) instead of the JDO 1.0.1 jar. This fixes an internationalization bug in the JDO 1.0.1 jar. It is no longer necessary to use the i18nhelper_websphere_patch.jar patch.

  • The JDO jar (now jdo-1.0.2.jar) file is no longer included in the resource adapter file (kodo.rar). The JDO jar file should be deployed in the global classpath for the application server.

  • Changed MaxCharactersInAutoIncrement property of DBDictionary to MaxAutoIncrementNameLength to match naming conventions of other length restriction properties.

  • kodo.datacache.TangosolCache now uses the CacheFactory.getCache() method if the TangosolCacheType property is left unset. As a result, the return value of TangosolCache.getDistributedCache() has been deprecated, and will not return accurate information if the TangosolCacheType configuration property is not set.

  • Optimistic transactions in which no changes have taken place will no longer obtain and commit a datastore connection when the JDO transaction is committed.

  • Simplified the DBDictionary class for easier extension and greater configurability. The changes may break existing custom dictionaries. The source code for the new dictionaries is included in your Kodo distribution to help you migrate your custom dictionaries.

  • The query improvements in this release required changes to the FilterListener interface, and its JDBCFilterListener subclass. The source code for Kodo's built-in listeners is included in your Kodo distribution to help you migrate your custom listeners.

  • The query improvements in this release also required minor changes to some FieldMappings. See the Javadoc and the samples in samples/jdo/ormapping for details.

  • kodo.jdbc.SQL queries have been deprecated. Use JDO 2 preview SQL queries instead. See Chapter 17, SQL Queries.

  • The FetchConfiguration.EAGER_FETCH_* constants have been deprecated in favor of constants that more accurately reflect the semantics of each fetch mode. See Section 5.7, “Eager Fetching”.

  • Attempting to query on an interface or abstract class without any persistent implementors will throw an exception.

  • Configuration of the management and profiling capabilities has been simplified. For more information, please see Chapter 12, Management and Monitoring and Chapter 13, Profiling.

• Bugfixes

  • Query parameter validation now ensures that you do not pass extra parameters to a Query.execute() invocation. This may cause some of your previously-functioning queries to fail to execute.

  • Corrected Empress database dictionary to use TOLOWER and TOUPPER SQL functions. Bug 964.

  • Removed restriction limiting arguments to the startsWith and endsWith JDOQL methods to literals and parameters. Bug 970.

  • Fixed possible exception when attaching new embedded objects.

  • Worked around JDO library bug with potential infinite recursion when printing out stack traces that contain a failed object whose toString method accesses persistent fields. Bug 979.

  • Fixed exception when supplying a null value for an implicit parameter.

  • Query caching behaves properly with mutable parameter types (Collection, Date) that are changed between executions (bug 959)

  • Queries that return no results are properly cached.

  • Projections can now contain the same column multiple times; bug 853.

  • Added support for non-persistence capable query variables; bug 720.

  • All return types from projections and aggregates, whether executed in-memory or in the data store, now exactly match the types specified by the JDO 2 early draft specification. Bug 721.

  • Fixed some cases of not being able to use variables in projection and aggregate queries executed in-memory. Bug 713.

  • Fixed bug that prevented a lock-group of none from working in some cases.

  • Fixed a bug that prevented the reverse mapping tool from recognizing the -s cmd-line argument shortcut for the -schemas option.

3.1.5 -- August 11, 2004

• Notable Changes

  • When setting kodo.ProfilingInterface to export, default export interval is now -1, indicating that only a final export will be created.

• Bugfixes

  • Fixed possible exception when attaching a new embedded object.

  • Included check for lock-group when using state-image version indicator.

  • Final profiling export when setting kodo.ProfilingInterface to export is now produced.

  • Fixed DBDictionary to allow column auto-increment sequence names longer than 31 by adding MaxCharactersInAutoIncrement property.

3.1.4 -- July 9, 2004

• New features

  • ClassDBSequenceFactory can now ignore horizontally mapped classes when determining primary key values.

  • Firebird is now a supported database. See Section 4.7, “Firebird”.

  • Borland Interbase is now a supported database. See Section 4.2, “Borland Interbase”.

• Bugfixes

  • Corrected bug in appidtool that could result in invalid application identity subclass generation when the application identity superclass had one or more Date primary key fields.

  • The reverse mapping tool now honors the DBDictionary's UseSchemaName property when deciding whether to qualify table names in generated mappings.

  • Fixed recently-introduced NullPointerException in some one-many mappings.

3.1.3 -- June 21, 2004

• New features

  • Subclasses in an application inheritance hierarchy can now define additional primary key fields. See Section 4.5.2.1, “Application Identity Hierarchies”.

  • The Kodo Development Workbench now includes options for previewing the metadata and mappings in XML form. In addition, you can now edit foreign keys and use them in the visualization process.

  • The reverse mapping tool accepts a new option -- -blobAsObject/-bo -- to map binary columns to java.lang.Object fields, rather than to byte[] fields. Enabling the option mirrors the tool's behavior in Kodo versions prior to 3.1.2.

  • Kodo will now issue warnings to the log when a mapping contains unrecognized attributes, or when a metadata extension contains an unrecognized key. The log message will include suggestions for similarly name attributes.

  • Kodo will now issue warnings to the log when an unrecognized property name is specified in the kodo.properties configuration file. The log message will include suggestions for similarly named properties.

• Notable Changes

  • The AbstractStoreManager.newInstance method no longer exists; use the KodoStateManager.initialize(Class,JDOState) method in its place.

• Bugfixes

  • Fixed bug with id class validation problems with NetBeans plugin.

  • Fixed bug that could cause errors after rollback of a transaction in which an object with dependent relations was deleted.

  • Fixed externalization bug that could lead to a ClassCastException when one container type was externalized to another container type.

  • Fixed bug with caching of queries that use empty Collection parameters (bug 944).

  • Fixed bug in which reverse mapping tool generated invalid Java code for binary columns.

  • Changed DB2 SQL generation to not use CROSS JOIN, which DB2 does not understand.

  • Fixed bug that prevented Workbench from allowing you to edit metadata for field that are non-persistent by default.

  • Fixed query bug that could result in a NullPointerException when attempting to constrain a variable to a collection or map passed in as a parameter (or traversed from a persistence-capable parameter).

  • Fixed mapping bug when mapping an embedded field of a horizontally-mapped superclass to a subclass table.

  • Corrected an unnecessary SELECT DISTINCT JDOCLASS when using PersistentClasses list.

3.1.2 -- May 21, 2004

• Bugfixes

  • Fixed 3.1.1 bug that prevented use under some licenses.

3.1.1 -- May 20, 2004

• New features

  • Support for embedded one-to-one mappings in Kodo Development Workbench.

  • Support for data compression and filtering when using remote persistence managers. See Section 11.2.4, “Data Compression and Filtering”.

  • Support for byte array primary key fields for legacy schemas that use binary columns for primary keys.

  • XML Store Manager sample now included.

  • The Kodo workbench now includes a live JDOQL query executor and result browser.

• Notable Changes

  • Changed default storage directory for Kodo Development Workbench from the current working directory to ${user.home}/solarmetric. Kodo Development Workbench will handle the migration for you. However, you can choose to override this behavior by using the -s argument to specify a different location.

  • Byte array fields are now mapped using the byte array field mapping by default, rather than the blob field mapping. The byte array mapping does not serialize its data, while the blob mapping does. This should not affect existing mappings.

  • The reverse mapping tool now maps binary columns to byte[] fields, rather than Object fields.

  • Downgraded non-locking SELECT log messages from WARN to INFO.

  • Integration of remotejmxtool with unsupported application servers can now be plugged in. See Section 12.2.1, “Remote Connection” for details.

  • Changed kodo.runtime.LockManager plugin API to allow the lock manager to access the connection info we are loading from, if any. This is useful for plugins that implement the kodo.jdbc.runtime.JDBCLockManager interface.

• Bugfixes

  • Changed class loading in Kodo tools so that static initializers of user-defined classes are not invoked in dev-time operation.

  • Fixed a possible constraint violation when using maps with restrict-action foreign keys to persistent object values. The error occurred when changing an existing map key and deleting the old value object.

  • Fixed a bug that could result in mapping errors when using numeric constant joins in combination with the dynamic schema factory.

  • Fixed a bug that could result in mappings to be generated for the implicit "jdoDetachedObjectId" field that is created when enhancing a detachable class. By default, any field starting with "jdo" will no longer be considered persistent unless it is explicitely declared.

  • Corrected an inefficiency in object locking that could result in a SELECT FOR UPDATE being issued for an already-locked object.

  • Fixed a bug that sometimes prevented Kodo from obtaining a requested database lock if the object was found in the data cache.

  • Removed potential deadlock in JDBCConfiguration.

  • Fixed bug that caused spurious graphical glitches and exceptions in JMX Management Console.

  • Removed a limitation that prevented non-serializable persistent instances from being used as parameters in a remote query. Note that this limitation is still in place for non-persistent instances.

  • Fixed bug that caused certain custom field mappings using java.sql.Date/Timestamp to get a ClassCastException.

  • Enabled App Id Tool to generate object identity classes for horizontally mapped classes.

  • Fixed ColumnVersionIndicator to throw correct lock exception on certain conditions with deleted rows.

3.1.0 -- April 23, 2004

• New features

  • Added new configuration properties and runtime APIs for enhanced control over object locking. See Section 9.4, “Object Locking” for details.

  • Kodo Development Workbench includes a number of new features and changes, including the ability to edit version and class indicators in the visualization editor.

  • You can now configure Kodo to evict objects from the data cache whenever you evict them from a persistence manager. See Example 10.9, “Automatic Data Cache Eviction”.

  • Added methods to KodoHelper to retrieve the data cache for an object or class.

  • Added example XML based AbstractStoreManager called kodo.xmlstore.XMLStoreManager.

  • Added support for large result set handling for fields declared as type java.util.Set.

  • Added support for constant joins in many-to-many relations, including mapping both a one-to-one and a many-to-many into the same join table.

• Notable Changes

  • Object locking APIs have changed. See Section 9.4, “Object Locking” for details.

  • Added support for interface mappings in JBuilder and SunONE/NetBeans plugins in addition to other usability and stability fixes. Users of these plugins should install the new versions.

  • ClassDBSequenceFactory now has a main (String[] args) method to create and drop required schema components.

  • The DBDictionary now supports the DefaultSchemaName parameter. See Section 4.4, “Database Support”.

  • Optimized statement batching within groups of SQL updates ordered to meet foreign key constraints.

  • The StoreManager API has changed slightly in light of the object locking enhancements in this release. See its Javadoc for details.

• Bugfixes

  • Fixed a bug in which the new lockPersistent APIs could cause errors if used during an optimistic transaction.

  • Fixed SQL generated for removing columns on Empress.

  • Created special case for LOB handling when using a Weblogic datasource connecting to an Oracle database to circumvent the fact that Weblogic wraps the native Oracle LOB-handling classes.

  • Fixed bug in which passing duplicate oids to KodoPersistenceManager.getObjectsById could result in internal errors.

3.1.0 RC2 -- March 24, 2004

• New features

  • Added the ability to use remote persistence managers over HTTP/HTTPS. See Chapter 11, Remote and Offline Operation for details.

  • Added an abstract store manager, which is a building block for allowing you to add support for non-relational data stores that Kodo does not support. See the kodo.abstractstore javadocs for documentation.

  • Added a SequenceGenerator.ensureCapacity(int count) method. Invoke this method to provide a hint to a sequence generator about how many times its next() method will be invoked.

  • Added support for Empress database.

• Notable Changes

  • Kodo Development Workbench has added some usability improvements in addition to a variety of bugfixes.

  • Eclipse plugin has now been changed to 2.1.0. This new version includes the ability to enhance and run Mapping Tool on multiple .jdo files at once. In addition, a more full range of Mapping Tool options such as readSchema and ignoreErrors are now available. The enhancer builder now delays til the end of building to avoid re-processing of metadata (and potential classloader issues related to this).

    This version of the plugin includes also a number of bug fixes. It is recommended that you uninstall the old version of the plugin by completely removing the old kodo.eclipse_2.0.0 directory and installing the new one.

  • Deprecated SequenceGenerator.getNext() in favor of SequenceGenerator.next(), which returns an unboxed long rather than a java.lang.Number.

  • Management capability now disabled by default. To find/create an MBeanServer and register MBeans set the kodo.MBeanServerStrategy configuration property. See Chapter 12, Management and Monitoring for details.

• Bugfixes

  • Fixed bug that caused intermittent errors in remote persistence managers when the primary key values of an application identity instance were changed after it was made persistent, but before commit.

  • Improved JBuilder plugin stability. Bugs fixed include proper handling of cancel, drop, and file organization.

3.1.0 RC1 -- March 10, 2004

• New features

  • Kodo now uses its own logging framework by default instead of the Commons Logging framework. To use the Commons Logging framework as in older versions of Kodo, set the kodo.Log property to commons. See Chapter 3, Logging for details.

  • Kodo Workbench now includes the ability to dynamically edit from the Visualization editor. Mapping Tool actions now work on the current instead of the saved versions of mapping information.

  • The kodo.jdbc.SynchronizeMappings property (which was known as com.solarmetric.kodo.impl.jdbc.SynchronizeSchema in version of Kodo prior to 3.0) now allows Kodo to dynamically attempt to build O/R mappings and the database schema at runtime. See Section 7.1.4, “Runtime Forward Mapping”.

• Notable Changes

  • Kodo's JCA connection factory can now be safely cast to a KodoPersistenceManagerFactory rather than just a PersistenceManagerFactory.

  • The reverse mapping tool now automatically strips illegal characters from table and column names when mapping them to Java identifiers. This is mostly a bug fix, but also affects users who have reverse customizer properties files renaming fields for which Kodo used to include invalid characters.

  • If the DBDictionary.StoreCharsAsNumbers property is set to false, CHAR(1) columns will be reverse-mapped to Java char fields rather than strings.

• Bugfixes

  • Fixed bug that caused Kodo to sometimes return an inaccurate size for query results when large result sets were enabled, the query involved to-many joins, and Kodo was configured to use SELECT COUNT to calculate the size.

  • Fixed bug preventing objects with null relations from being returned when those relations were eager-fetched and were to subclasses using vertical inheritance.

  • Fixed bug that caused a parse error when attempting to case with the full class name in a JDOQL filter string (i.e. "((com.xyz.Foo) foo).bar == x"). Bug 869.

  • Fixed bug in which fields declared in the class of the cast were sometimes not recognized when casting in JDOQL filter string. Bug 805.

  • The SELECT COUNT subselect issued when testing for a null 1-1 or empty collection/map in a query filter now uses the fully qualified table name (including schema).

  • Fixed NullPointerException when passing an array or collection containing null elements to certain persistence manager methods such as retrieveAll.

  • Fixed bug involving the customization of reverse-mapped field names. Bug 881.

  • Fixed reverse-mapping problem with Informix databases.

  • Fixed error when you add a new instance to an ordered one-many relation, flush, then extensively modify or re-order the elements of the relation, then commit. Bug 887.

3.1.0b1 -- February 16, 2004

• New features

  • Kodo now supports the "horizontal" O/R inheritance model, where each leaf of the inheritance hierarchy is mapped to a separate table. for details.

  • Added the ability to use Kodo from remote client machines communicating with a persistence manager server. See Section 11.2, “Remote Managers” for details.

  • Improved effeciency of the query compilation cache. After a query is compiled or executed once, subsequent compilations or executions of queries with the same properties (even in different persistence managers) are much faster.

  • Added custom lock group support, allowing field-level optimistic locking granularity. See Section 5.8, “Lock Groups” for details.

  • Added object locking APIs to the KodoPersistenceManager for fine-graned control over object locking. You can also plug in your own locking scheme through the kodo.LockManager configuration property.

  • Added a cancelAll method to the KodoPersistenceManager that can be used to cancel any outstanding database statements issued by a PersistenceManager.

  • Added a new option for controlling how Kodo queries against class hierarchies that use vertical inheritance mapping. See Section 5.7, “Eager Fetching” for details.

  • Sigificantly improved technology preview of Kodo Management / Monitoring capability based on JMX. Includes local and remote management functions, management of Data cache, Prepared Statement cache, and Kodo Datasource Connection Pool, and advanced performance analysis. See Chapter 12, Management and Monitoring for details.

• Notable Changes

  • kodo.jdbc.meta.ClassMapping and kodo.jdbc.meta.FieldMapping are now interfaces. Custom implementations that previously extended these classes directly should now extend kodo.jdbc.meta.AbstractClassMapping and kodo.jdbc.meta.AbstractFieldMapping.

  • The KodoQuery.FLUSH_* constants have been deprecated in favor of equivalent constants in the FetchConfiguration interface for easier access.

• Bugfixes

  • Fixed bug with inovking size() on query results returned from SQL queries when using lazy result support.

3.0.3 -- February 20, 2004

• New features

  • Added a ref-constant attribute type to mapping data, so that you can perform constant joins (see Section 7.6, “Non-Standard Joins”) on reference foreign keys, such as those used in one-many mappings.

  • Manually flushing the persistence manager before commit now releases all hard references to flushed dirty objects, allowing you to insert or update an unlimited number of objects within the same transaction without running out of memory.

  • Added the new kodo.runtime.PreDetachCallback, kodo.runtime.PostDetachCallback, kodo.runtime.PostAttachCallback and kodo.runtime.PreAttachCallback interfaces that allow instances to be notified when they are being detached or attached.

  • Added support for simulating auto-increment fields under Oracle by using triggers. See Section 4.4.3, “OracleDictionary Properties”.

  Notable Changes

  • Deprecated the KodoPersistenceManager.getState method in favor of the new KodoPersistenceManager.getStateManager method, which takes in a persistence capable instance rather than an object id. The actual instance is required to make sure that the correct state is returned when multiple persistent-new application identity objects have the same object id. This is possible if they are persisted before their primary key fields are set to unique values and the transaction has not yet committed.

  • The data cache now does not do any copying of Locale objects, as they are final and immutable. This means that if you cache an object with a Locale reference and then load that object from cache at a later time, the Locale will be identical (== will pass) in both objects.

  • The Mappings.getForeignKey and Mappings.setForeignKey custom mapping helper methods now automatically suffix the given attribute prefix with -column (use null for an attribute of column).

• Bugfixes

  • Fixed bug that sometimes prevented changes in positions of ordered list elements from being committed to the database.

  • Stopped Kodo from occasionally iterating large result set fields on load and flush.

  • Fixed bug that left open result sets when using large result set fields of first class objects.

  • Fixed bug with caching of Date and mutable (proxied) custom SCO field types.

  • Fixed bug with improper lookup of unloaded related objects from cache (bug 836).

  • Fixed bug that caused eagerly-fetched to-many fields to sometimes not contain all elements if the field elements were constrained in the query being executed (bug 855).

  • Fixed bug that could cause exponential rise in commit time when committing many interrelated new objects.

  • Fixed bug that prevented multiple new instances from being able to be attached if they used application identity (bug 848).

  • Fixed bug that prevented attaching a graph that made a newly added instance persistent if it was reachable via multiple paths (bug 860).

3.0.2 -- January 24, 2004

• New features

  • Added a TableTypes property to the DBDictionary to allow configuration of the table types that will be considered when reflecting on the schema.

  • Added a jdbc-version-ind-indexed and jdbc-class-ind-indexed class metadata extensions to control the indexing of version and class indicator columns, respectively.

  • The DBDictionary now supports the InitializationSQL, CatalogSeparator, and UseSchemaName parameters. See Section 4.4, “Database Support”.

  • Allow application identity classes to use custom sequence factories for their sequence generators.

• Notable Changes

  • Made version indicator columns indexed by default. The next time you run the mapping tool's refresh action, you may see indexes added to existing version indicator columns. To prevent this, set the new jdbc-version-ind-indexed class metadata extension to false.

  • Fixed bug that prevented the mapping tool's buildSchema action from adding indexes to the class and version indicator columns.

  • Changed the default BatchLimit DBDictionary setting for Oracle 9.2 Driver to handle statement batching issues. Users connecting using the recommended 9.0.1 driver are unaffected.

• Bugfixes

  • Fixed bug that caused invalid SQL when using the mapping tool's buildSchema action under Sybase.

  • Fixed bug that prevented the mapping tool's buildSchema action from adding indexes to the class and version indicator columns.

  • Fixed bug that caused invalid SQL when using large result set collection or map fields with types with compound primary keys.

  • Fixed bug that prevented inserts or updates of BLOBs over 4K in Oracle if the BLOB column had a NOT NULL constraint.

  • Fixed rare NullPointerException in query compilation cache.

  • Fixed problems with SybaseDictionary's handling of BigDecimal and BigInteger values.

  • Fixed bug that sometimes led to duplicate objects in query results due to missing DISTINCT in database select.

  • Fixed issue with re-attaching detached instances with generic/unknown type fields.

  • Fixed metadata parsing issue with classes loaded under the bootstrap classloader in certain situations.

  • Fixed memory leak when invoking Query.close() (as opposed to Query.closeAll()) on a cached query.

3.0.1 -- December 16, 2003

• New features

  • Includes technology preview of the standalone Kodo Development Workbench. Kodo Development Workbench provides integrated mapping tools for your Kodo development, including metadata editors, visual relational graph analysis, configuration wizards, and access to development tools such as SchemaTool and Reverse Mapping Tool

  • Added new Byte Array Field Mapping. This mapping avoids serialization of byte array fields for interactions with non-Java applications.

  • The sqlline.jar utility is now included in the Kodo distribution. It is useful for a unified command interface for any database. See Section 4.15, “The SQLLine Utility”, and for complete documentation, see http://sqlline.sourceforge.net.

  • Added support for expressing nested O/R mapping extensions via XDoclet.

  • Introduced a cache for shareable query-related information. This improves query compilation times in many situations. See Section 2.7.52, “kodo.QueryCompilationCache” for details.

  • Added a class-criteria attribute to the one-one mapping.

  • Added support for naming and configuring multiple data caches via the kodo.DataCache configuration property. See Section 10.1.1, “Data Cache Configuration” for details.

• Notable Changes

  • Query extensions and aggregate queries are now included as part of Kodo Standard Edition; Enterprise Edition is no longer required to utilize these features.

  • Changed connection pool to reduce concurrency when creating and closing connections.

  • Changed the default value of the kodo.AutoClear flag to all to comply with JDO 1.0.1 spec section 5.8. Note that this gives behavior similar to previous versions of Kodo; the change we made to the default behavior in Kodo 3.0 was incorrect.

  • Connection Decorators and JDBC listeners now do their work on all connections, inclusive of DBDictionary access.

  • Changed the handling of dependent fields to allow you to move dependent objects to other fields in a transaction. Kodo now only deletes dependent objects that have been removed from their owning field or had their owning object deleted, and that have not been assigned to any other field of any object. This analysis occurs on flush.

• Bugfixes

  • Fixed bug that prevented runtime licenses from working.

  • Optimized query compilation for datastore execution, not in-memory execution.

  • Fixed bug that inserted invalid rows into map tables when an existing key of a persistent map field was given a new value.

  • Fixed bug that caused direct SQL queries to throw an exception when executed in a transaction, even when no objects had been modified in the transaction and/or the global javax.jdo.IgnoreCache property was set to true.

  • Fixed bug that prevented the file mapping factory from working correctly when the path to metadata files contained spaces.

  • Fixed bug with Ant and Mapping Tool classloader conflict which caused ClassNotFoundExceptions.

  • Fixed bug 798 -- potential memory leak when query caching is enabled.

  • Fixed a bug that caused inverse-based one-many and one-one mappings without an inverse-owner to somtimes produce bad SQL if the inverse columns were mapped to other fields as well, or were not nullable.

3.0.0 -- November 7, 2003

• New features

  • Kodo now supports direct SQL queries and stored procedure calls through the javax.jdo.Query interface. See Chapter 17, SQL Queries for details.

  • Technology preview of Kodo Management / Monitoring capability. See Chapter 12, Management and Monitoring for details.

• Notable Changes

  • Added documentation for deploying in JRun 4.

  • The ext:namedQuery JDOQL extension has been replaced with the kodo.MethodQL query language. See Section 9.6.5, “MethodQL” for details.

  • By default, the mapping tool no longer reads the entire existing schema on startup, though this option is still available. Also, the mapping tool does not examine or manipulate indexes, foreign keys, or primary keys on existing tables by default, though these options, too, are available as flags.

• Bugfixes

  • Fixed a bug that produced incorrect and sometimes invalid SQL when eager-fetching an inverse one-one relation.

  • Fixed a bug introduced in RC 3 that could cause collections and maps to be loaded as null whenever the data cache was enabled.

  • Fixes bugs in the IDE plugins. Please re-install any previous installations before installing the new versions of the plugin.

3.0.0 RC4 -- October 31, 2003

• Notable Changes

  • The jdbc-use-* metadata extensions have been renamed to jdbc-*-name extensions. So, for example, the jdbc-use-class-map extension is now jdbc-class-map-name. This change actually happened in RC3, but was not fully documented.

3.0.0 RC3 -- October 31, 2003

• New features

  • Added a KodoHelper.getSequenceGenerator method to ease obtaining a sequence for application identity classes.

  • Built-in support for Borland JDataStore, as well as Microsoft Access and Microsoft Visual FoxPro (using a JDBC-ODBC server bridge like DataDirect, but not the Sun JDBC-ODBC bridge).

• Bugfixes

  • Fixed synchronization problem that could result in a ConcurrentModificationException when Kodo is used under high load with managed transactions.

  • Fixed problem with incremental flushing that made it impossible to edit an existing object, flush, and then delete.

  Notable changes

  • The behavior of the data-cache-timeout metadata extension has changed considerably. In previous release candidates, a value of 0 meant that a class should never expire, and a value of -1 meant that the class should be excluded from the cache altogether. As of this version, a value of -1 means that the data in the cache should not expire, and is the default. 0 is no longer a valid value.

    Additionally, the data-cache-name metadata extension's name has been changed to data-cache. Its role has been expanded to control disabling caching for a particular cache. To disable caching, set the data-cache extension to false. The default value for this extension is true.

    So, to sum up, if you had a data-cache-timeout extension set to 0, you will get an exception when the metadata is parsed. Change the value to -1 instead. If you had set the extension to -1, then things are a bit trickier -- this will change the semantic behavior of your class unless you remove the extension and set the data-cache extension to false.

  • Removed the xa option from the kodo.TransactionMode configuration property. When using an XA data source or other data source that is automatically involved in the global transaction, set kodo.TransactionMode to managed and set the new kodo.jdbc.DataSourceMode property to enlisted.

  • The default value for javax.jdo.option.IgnoreCache has been changed from false to true.

  • Refactored data caching to not lock the cache as a whole when loading data from it or storing data into it. This change improves the concurrency of the cache.

  • Removed the kodo.DataCacheConnects property, as it is not needed now that locks are not obtained on the data cache.

  • Re-worked SunONE/NetBeans and JBuilder plugins to remove a number of bugs as well as to improve the UI. Editors now incorporate commonly used Kodo extensions. For users of earlier versions, we recommend un-installing and re-installing the plugin.

  • Made assorted minor tweaks to prepared statement and query caching.

3.0.0 RC2 -- October 9, 2003

• New features

  • None

• Bugfixes

  • Fixed an optimistic locking error when the data cache is enabled.

  • Fixed some minor attach/detach bugs.

  • Fixed a bug in which persistent non-transactional objects were not cleared and reloaded when dirtied in an optimistic transaction. This could lead to false optimistic lock exceptions. See notable changes section below for details.

• Notable changes

  • Added the kodo.DataCacheConnects property to determine whether the data cache obtains a connection before each cache access. See the last list item in Section 10.1.8, “Known Issues and Limitations” for details.

  • Kodo now clears and reloads persistent non-transactional objects when they are dirtied in an optimistic transaction. This is correct behavior as far as the spec is concerned, but can result in lower performance than the previous non-clearing behavior under certain usage patterns. Also, this change means that non-transactional writes can no longer be committed. Users who would like to continue with the old non-clearing behavior in order to increase performance or allow non-transactional writes to be committed should set the kodo.AutoClear configuration property to all. Users of optimistic transactions and non-transactional reads who choose not to set this property should watch out for the following usage pattern:

    Person p = (Person) pm.getObjectById (oid, true);
    pm.currentTransaction ().begin ();
    p.setName ("New Name");    // this now causes a reload of the object state!
    pm.currentTransaction ().commit ();
    

    If you are looking up data in order to modify it, make sure to look it up within the transaction rather than just before the transaction, and thus avoid a state refresh.

3.0.0RC1 -- 23 September 2003

• New features

  • Support for detaching and attaching instances from a persistence manager, allowing applications to more easily use a "data transfer object" pattern.

  • Support for collection and map fields that are backed by large result sets.

  • Support for additional settings to control the handling of large result sets.

  • Better exception messages when mappings can't be found or fail validations against the schema.

• Bugfixes

  • Fixed many eager-fetching SQL errors.

• Notable changes

  • Kodo now uses non-scrolling result sets by default, and fetches all query results up-front by default. See the large result set section of the reference guide for how to configure large result set handling if needed.

  • The JDBCQuery's JoinSyntax property has been moved into the query's JDBCFetchConfiguration. You should no longer cast to JDBCQuery, since that cast can fail when the data cache is enabled. Use the fetch configuration instead.

3.0.0b2 -- 3 September 2003

• New features

  • Expanded smart proxies to include change-tracking for lists.

  • Kodo now examines the initial field value of managed fields and stores any custom comparators for use when loading data into that field from the database.

  • Added the kodo.RestoreMutableValues configuration property.

  • IDE plugins have been re-implemented for Kodo 3. Support for NetBeans, SunONE Studio, JBuilder, and Eclipse have been re-added. Uninstall previous versions of the plugin, and follow the documentation for each plugin's installation.

  • New externalization system for storage of field types not supported by JDO without resorting to serializing or requiring custom mappings. Replaces the old stringification mapping.

  • Support for aggregates and projections in queries. See Chapter 11, Query for details.

  • Added a matches query extension for limited regular-expression matching in JDOQL. See the Included Query Extensions documentation for details.

  • Documentation for how to use the latest builds of XDoclet to generate JDO metadata from source comments is now in the Integration chapter of the reference guide. A new XDoclet sample was also added to the samples/ directory.

  • Added APIs for get/setRollbackOnly to the KodoPersistenceManager interface.

• Bugfixes

  • Fixed a bug in the first beta that prevented MySQL tables with VARCHAR columns from being created correctly.

  • Fixed a bug in the first beta that prevented eager-fetching from working efficiently. Also fixed some cases that could lead to stack overflow errors when using eager fetching.

  • Fixed a case in which compound primary keys could sometimes cause array index out of bounds errors when retrieving objects.

  • Fixed the Kodo 2 migrator tool, which sometimes specified arrays with the <collection> element in the migrated metadata.

  • Improved support for columns shared by both relation foreign keys and simple value fields.

  • Improved error messages when setting the same column to multiple different values or when trying to insert multiple objects with the same oid.

• Notable changes

  • Configuration properties specifying system plugins have been consolidated. See the Plugin Configuration section of the Configuration chapter for details. Beta 1 users may want to re-run the Kodo 2 properties migration tool on their old Kodo 2 properties instead of modifying their beta 1 properties by hand.

  • The default mapping factory has been changed to the file-based factory. If you were using the default database mapping factory in beta 1, either switch to the file mapping factory, or add the following line to your properties file:

    kodo.jdbc.MappingFactory: db
    

  • Changed the default table and column names for the DBSequenceFactory. If you were using the DB sequence factory in beta 1, either re-run the Kodo 2 properties migration tool, or add the following line to your properties:

    kodo.jdbc.SequenceFactory: PrimaryKeyColumn=PKX, SequenceColumn=SEQUENCEX, \
        TableName=JDO_SEQUENCEX
    

  • The stringification field mapping was replaced by the externalization framework.

  • The stringContains and wildcardMatch query extensions have been deprecated in favor of the matches query extension.

3.0.0b1 -- July 24, 2003

• New features

  • New mapping system, providing more flexible mapping options. See the chapter on Object-Relational Mapping for more information.

  • Pluggable system for storing mapping information, with built-in options for storing mapping information in the database, in JDO metadata extensions, and in a separate mapping file. See the section on the Mapping Factory for more information.

  • Support for embedded 1-1 mappings, including nested embedded mappings with no limit on nesting depth. See the section on Embedded One-to-One Mapping for more information.

  • More complete mapping support for interfaces, including support for interfaces as the element type of collections, and the key and value types of maps. See the section on Field Mapping for more information.

  • Support for other-table mappings with outer joins. See the section on Value Mapping for more information.

  • Support for 1-many fields without an inverse 1-1 field. See the example Using a One-Sided One-to-Many Mapping in the section on One-to-Many Mappings for more information.

  • Support for first class objects as map keys. See the sections on Many-to-N Map Mapping, Many-to-Many Map Mapping, PC Map Mapping, PC-to-N Map Mapping, PC-to-Many Map Mapping, and Many-to-PC Map Mapping in the section on Field Mapping for more information.

  • Support for non-standard joins, including partial primary key joins, non-primary key joins, and joins using constant values. See the section on Non-Standard Joins for more information.

  • New samples for custom field mappings. The samples/jdo/ormapping directory of the Kodo JDO distribution includes examples of custom mappings.

  • Support for automatically ordering SQL operations to meet all foreign key constraints, including circular constraints.

  • Support for javax.jdo.option.NullCollection .

  • Support for timestamp and state-based optimistic lock versioning, and for custom versioning systems. See the section on Version Indicators for more information.

  • More configuration options for connection pooling. See the section on kodo.ConnectionFactoryProperties for more information.

  • Support for SQL logging on third-party javax.jdo.DataSources.

  • Configurable eager fetching of 1-1, 1-many and many-many relations. Potentially reduces the number of database queries required when iterating through an extent or query result and accessing relation fields of each instance.

  • Ability to obtain both managed and unmanaged persistence managers from the same PersistenceManagerFactory .

  • Support for auto-increment fields.

  • Better support for auto-incrementing primary keys.

  • More optimized SQL batching.

  • Fail-fast error messages when object-relational mappings, class definitions, and schema are not in synch.

  • Automatic schema generation now names schema components better, and automatically avoids naming conflicts with existing schema components.

  • Simplified package structure and plug-in APIs. See the section on JDO Runtime Extensions for more information.

• Bugfixes

  • Fields in the same class hierarchy which share the same name no longer cause an invalid schema.

• Notable changes

  • A series of steps must be followed in order to migrate from Kodo 2.4 or Kodo 2.5 to Kodo 3.0. Please see Migrating from Kodo 2 to Kodo 3 for more information.

  • The schematool has been replaced with the more powerful mappingtool. The schematool still exists, but now has a different purpose. See the section on Schema Tool for more information.

  • In Kodo 2.x, the default-fetch-group was not loaded when an object transitioned from hollow to a stateful state because a non-default-fetch-group field was loaded. Because InstanceCallbacks.jdoPostLoad() is invoked after the default-fetch-group is loaded, this meant that the jdoPostLoad() callback was not invoked in some circumstances when it might otherwise be expected to be invoked. kodo 3 always loads the default-fetch-group when an object transitions from hollow, so jdoPostLoad() will now be invoked in situations in which it was not invoked in the past.

• Beta Notes

  • Integration with the supported IDEs is not included in 3.0.0b1. IDE integration will be included in later distributions.

  • XDoclet integration is not included in 3.0.0b1. It will be added in a later release.

  • Support for DB2, Informix and Sybase is not included in 3.0.0b1. Support for these databases will be included in later distributions.

  • Enterprise integration is not fully tested in 3.0.0b1. Full testing and support for will be included in later distributions.

2.5.5 -- 18 October 2003

• Bugfixes

  • Fixed synchronization problem in EEFactoryHelper that could result in a ConcurrentModificationException when Kodo is used under high load with managed transactions.

  • Fixed problem with checking the optimistic lock version of a subclass that uses a vertical inheritance mapping strategy.

• Notable changes

  • Refactored data caching to not lock the cache as a whole when loading data from it or storing data into it. This change improves the concurrency of the cache.

  • Removed the com.solarmetric.kodo.DataCacheConnects property, as it is not needed now that locks are not obtained on the data cache.

  • Made assorted minor tweaks to prepared statement and query caching.

2.5.4 -- 7 October 2003

• Bugfixes

  • Fixed bug with extents not closing resources with certain ResultList implementations due to internal iterators not closing.

  • Fixed bug with data caching and incremental flushing and loading that could result in incorrect OptimisticLockExceptions being thrown.

  • Fixed bug with data caching that could result in deadlocks when used in conjunction with table-level or page-level locking.

• Notable changes

  • Added the com.solarmetric.kodo.DataCacheConnects property to determine whether the data cache obtains a connection before each cache access. Note that this property defaults to false , which mirrors Kodo 2.5.2 behavior. Users who experienced data cache hangs in Kodo 2.5.2 because of empty connection pools should set this property to true to mirror Kodo 2.5.3 behavior.

2.5.3 -- 27 August 2003

• Bugfixes

  • Fixed bug with invalid SQLServer SQL92 generation when using pessimistic locking.

  • Addressed performance issues caused by recomputing persistent type lists and subclass lists too often.

  • Fixed result list implementation used by the query caching framework to properly lazily load results.

  • Fixed DataCacheStoreManager to properly deal with creating a new query based on a template that is a CacheAwareQuery, and changed CacheAwareQuery to have a writeReplace() method that returns the delegate query object rather than the cache-aware query.

  • Fixed bug that prevented custom query extensions from being recognized.

  • Fixed bug with data caching and incremental flushing that could result in incorrect OptimisticLockExceptions being thrown.

  • Changed on-demand ConnectionRetainMode to only obtain a single connection per PersistenceManager. In other words, if a PM is using a connection (for example, while iterating a large query result), and it performs an operation that requires a connection, it will use the previously-obtained connection rather than obtaining a new connection. This reduces resource consumption, and helps to avoid possible race conditions while obtaining connections. If the old on-demand ConnectionRetainMode is necessary for some reason, it can be activated by setting com.solarmetric.kodo.impl.jdbc.ConnectionRetainMode to legacy-on-demand.

  • Fixed potential race condition when performing operations on the data cache that might require a trip to the data store.

• Notable changes

  • Improved validation of application ID object-id classes may cause errors when enhancing or deploying malformed classes. These should be easily fixable by modifying your object-id classes to conform to the JDO specification rules.

  • Changed OnDemandForwardResultList to not use weak or soft references, but instead to optionally use a scrolling window to prevent memory growth as large result sets are iterated.

2.5.2 -- 4 July 2003

• Bugfixes

  • The repackaged concurrent.util APIs have been included in the released jars.

  • Fixed potential rounding bug where the fractional parts of a Date field can be doubled when using JDK 1.4.1.

  • Fixed problem where AutoIncrementSequenceFactory was not working for SQL Server.

• Notable changes

  • Changed the ConnectionRetainMode fix that was made in 2.5.1 to not actually close the PersistenceManager, replicating the behavior of 2.5.0 and earlier. This means that session beans that return live JDO objects without detaching them or copying them into data transfer objects will continue to function as with 2.5.0 and earlier releases. It is likely that Kodo 3.0 will deal with this differently, possibly including a mode to allow the current, more lenient behavior.

2.5.1 -- 4 July 2003

• New Features

  • Added ability to use database-specific outer join syntax. Coded Oracle 8i outer joins into Oracle dictionary.

  • Borland Enterprise Server is now supported, meaning that the AutomaticManagedRuntime class knows about where Borland puts its transaction manager in JNDI. In addition, the J2EE tutorial has been updated with detailed desployment instructions for Kodo as a JCA Resource Adapter.

• Bugfixes

  • Eclipse/WSAD plugin ClassLoader problems resolved. Please update the plugins/com.solar.../kodo-jdo.jar to the latest release.

  • Fixed ConnectionRetainMode=persistence-manager to correctly close resources when used in a container-managed transaction context. This fix may cause applications that use session beans but do not properly ( serialize | clone | makeTransient ) persistence-capable objects returned from the session beans to throw exceptions stating that a PersistenceManager has been closed. This can only be an issue if your session bean is deployed to the same JVM as the EJB client code.

  • Deadlocking problem with upgrading read locks in data cache has been resolved.

  • Optimistic lock version problem when RetainValues is false was resolved.

  • Connection leak problem in AutoIncrementSequenceFactory was resolved.

  • Improved performance of JDO class initialization in environments with potentially slow classloaders, such as JBoss.

• Notable changes

  • The included distribution of Apache Commons Logging is now 1.0.3. Be sure to update your classpath accordingly as there were some difficult to diagnose configuration bugs in 1.0.2. The JCA rar file has been updated with the newer version.

  • The UsePreparedStatements option has been removed: prepared statements are now always used for all drivers.

  • Made all queries using unbound variables use SELECT DISTINCT.

  • Kodo once again forces the prepared statement pool size to zero when using Microsoft's JDBC driver. You can prevent Kodo from doing this by setting the com.microsoft.jdbc.sqlserver.SQLServerDriver.nopool system property. See http://bugzilla.solarmetric.com/show_bug.cgi?id=501 for details.

2.5.0 -- 5 June 2003

• New features

  • Custom fetch groups are now supported. See the fetch group documentation and the FetchGroups configuration documentation for more information.

  • Participation in a global XA-compliant transaction is now possible in a managed environment.

  • Multi-table mappings now permit different tables to have different primary key column names.

  • The ProxyManager now includes capabilities to proxy user-defined mutable field types that are not part of the JDO specification.

  • Kodo now supports auto-increment columns when using datastore identity. See the sequence-factory-class metadata extension and SequenceFactoryClass configuration property documentation for usage details.

  • New flush API allows the modifications made in a transaction to be incrementally flushed to the database before transaction commit time. See the com.solarmetric.kodo.runtime.KodoTransaction.flush() JavaDoc for details.

  • Added subclasses of JDOUserException for special cases that are of interest: com.solarmetric.kodo.runtime.OptimisticLockException and com.solarmetric.kodo.runtime.ObjectNotFoundException.

  • New Kodo J2EE integration tutorial. See the J2EE documentation as well as the source code before proceeding. Currently, the tutorial includes instructions for WebLogic 6.2 and higher, SunONE Application Server 7, WebSphere 5, and JBoss 3.x.

  • The association between a PersistenceManager and a JDBC Connection can now be configured. The default behavior is the same as in earlier versions of Kodo -- connections are obtained on-demand. Additionally, Kodo can be configured to retain a connection for the duration of a transaction (both optimistic and pessimistic) or for the duration of a PersistenceManager's life cycle. This behavior is controlled with the com.solarmetric.kodo.impl.jdbc.ConnectionRetainMode configuration property.

  • Enhancement-time validation of JDO metadata has been improved. This may result in errors next time you recompile and re-enhance your persistence-capable classes.

  • Modified persistence-capable classes can be grouped by class before being flushed to the data store, increasing the potential for performance benefits due to statement batching. See the ClassGroupStateManagerSet documentation for details about this option.

  • Added direct support for custom collections and maps that implement ProxyCollection or ProxyMap, and for fields that implement Proxy.

  • Informix IDS is now a supported database.

  • Second-class objects that are externalizable to Strings can now be stored to string fields. See the Storing Second Class Objects via Stringification documentation for more information.

  • Data caching framework now caches JDOQL queries. See the Kodo JDO Query Caching section for more details.

  • Data caching framework includes semantics for specifying a timeout for a given class. See the Metadata documentation for more details.

  • Different classes can use different PersistenceManagerFactory caches, allowing for varying cache policies on a per-class basis.

  • A transaction event listener framework has been created. This framework allows listeners to be notified of transaction begin, commit, and rollback events on a per-PersistenceManager level, and of transaction commits on a per-PersistenceManagerFactory level. Additionally, this framework allows transaction commit notification to be propagated to remote PersistenceManagerFactory objects. See event notification framework documentation for more information.

  • The schema manipulation done by the SequenceFactory to initialize any database-specific tables to store sequence information is now done when the schematool is run, rather than at runtime.

  • Queries have received a major overhaul. Queries now support unbound variables, Collections as parameters to generate SQL IN (...) clauses, traversing fields of persistence-capable parameters, and more. The SQL produced by queries is also much more efficient.

  • The Query FilterListener API has changed, and the default set of available FilterListeners has been enhanced with a few new and powerful extensions. Some of the old extensions have been deprecated, so check the Query Extensions section of the documentation for details on the new extensions framework. Additionally, it is unlikely that existing custom query extensions will continue to work.

  • Added the com.solarmetric.kodo.impl.jdbc.UseSQL92Joins configuration property. Set this property to true to use SQL 92-style joins in queries, including left outer joins where appropriate. (This is the default value.) You can also set this property on an individual query instance; see the com.solarmetric.kodo.impl.jdbc.query.JDBCQuery class Javadoc for details.

  • PersistenceManager.newQuery(Class) and PersistenceManager.getExtent(Class) can now take an interface as a parameter, even when multiple separate inheritance hierarchies implement the interface and exist in the data store. Ordering for queries will work as expected, but it should be noted that an ordered query that is exected against multiple tables will result in partial loss of large result set support, such that attempting to access element N in the Collection returned from Query.execute() will force the results 0..N-1 to be instantiated so that an in-memory comparison of the homonegous objects can take place.

  • The new properties com.solarmetric.kodo.ResultListClass and com.solarmetric.kodo.ResultListProperties can now be used to specify a custom implementation of the CustomResultList interface that will be used to hold queries.

  Notable changes

  • The distributed data cache framework has been changed to use the transaction event listener framework to communicate commit information to remote JVMs. This means that deployments that use distributed caching must set up the com.solarmetric.kodo.RemoteCommitProviderClass and com.solarmetric.kodo.RemoteCommitProviderProperties configuration properties appropriately. Additionally, communication-related configuration properties in the com.solarmetric.kodo.DataCacheProperties must be removed.

    For example, to configure Kodo to use JMS for distributed commit notification, your properties would look like so:

    com.solarmetric.kodo.DataCacheClass: com.solarmetric.kodo.runtime.datacache.plugins.CacheImpl
    com.solarmetric.kodo.RemoteCommitProviderClass: com.solarmetric.kodo.runtime.event.impl.JMSRemoteCommitProvider
    com.solarmetric.kodo.RemoteCommitProviderProperties: Topic=topic/KodoCacheTopic
    

    To configure Kodo to just share commit notifications among PersistenceManagerFactories in the same JVM, your properties would look like so:

    com.solarmetric.kodo.DataCacheClass: com.solarmetric.kodo.runtime.datacache.plugins.CacheImpl
    com.solarmetric.kodo.RemoteCommitProviderClass: com.solarmetric.kodo.runtime.event.impl.SingleJVMRemoteCommitProvider
    com.solarmetric.kodo.RemoteCommitProviderProperties: Topic=topic/KodoCacheTopic
    

  • The UDPCache distributed data cache plug-in has been removed. People interested in using UDP for cache invalidation should implement the com.solarmetric.kodo.runtime.event.RemoteCommitProvider interface.

  • The DataCache interface and associated implementations have been overhauled in a number of ways. As a result, it is unlikely that previously-created DataCache implementations will work with Kodo 2.5.

  • When IgnoreCache is set to false and a query is executed after modifications to instances that are in the query's access path, Kodo may automatically flush all modifications in the current transaction to the database, and performs the query against the data store. The behavior depends on numerous settings; see FlushBeforeQueries for details. Previous releases of Kodo evaluated these types of queries in-memory, which can incur a considerable performance penalty.

  • Added a validation to ensure that ordering strings explicitly use either ascending or descending correctly, and do not specify any other values for the ordering.

  • Eclipse/WSAD plugin has changed to 1.0.1. The Kodo view is now located in the Java grouping, as opposed to Debug. The plugin is now compatible with Eclipse 2.1. In addition, the required jars in the plugin.xml has been changed to include Jakarta's lang jar (included with the distribution). The plugin should be reinstalled (remove the old com.solarmetric... directory and reinstall according to the documentation).

  • NetBeans/SunONE plugin users should install the Jakarta lang jar from the distribution into the lib/ext directory of their installation. In addition, serp.jar should be removed as it is now part of the regular distribution and is no longer needed. See the full list of required jars in the SunONE/NetBeans portion of the documentation.

• Bugfixes

  • Fixed datacache issue with over-eager loading of relations.

  • Fix for potential inefficiency when many threads concurrently access the data cache.

  • Fixed finalization bug in connection pooling that allowed closed connections to be returned from the connection pool.

  • Placed subselects in generated SQL for isEmpty on right side of expression to placate DB2.

  • Using persistence-capable parameters that implement Collection or Map in a JDOQL query now works.

  • Assorted minor bugfixes and error message improvements.

  • Method name misspelling in com.solarmetric.kodo.impl.jdbc.SQLExecutionListener has been fixed. As a result, implementations of this interface must be changed to use the correctly-spelled method name.

  • Merged 2.4.3 bugfixes. See below.

  • Fixed many query bugs.

2.4.3 -- 26 March 2003

• Notable changes

  Bugfixes

  • Included a new version of serp that resolves issues with weak and soft references that can lead to memory leaks. Be sure to copy the new serp jar into your lib dir as well as the new Kodo jars.

  • Fixed a bug in ClassDBSequenceFactory to address potential concurrency issues that could lead to a deadlock while obtaining new ID values.

  • Fixed AbstractDictionary to deal with null Locale objects properly.

2.4.2 -- 26 Feb 2003

• Notable changes

  • The SunONE Studio / NetBeans plugin module has moved into release status. Existing module users should un-install and re-install the module.

  • The Eclipse / WSAD plugin has moved into release status. Note that the plugin folder structure has changed to reflect this change. Existing plugin users should remove the old folder, install the new folder, and update the plugin.xml accordingly. Included in this new version are changes in classpath and project resolution.

  Bugfixes

  • Mutating a Date field via deprecated setDate(), setHour(), etc. now properly dirties the owning object.

  • Fixed LocalCache synchronization issue.

2.4.1 -- 26 January 2003

• New features

  • New subclass provider implementation option simplifies using an integer lookup value to store subclass information in the database. Additionally, the source for this implementation is included in the release, so creating a custom subclass provider is simpler.

  • We now set the default transaction isolation level to TRANSACTION_SERIALIZABLE when using DB2. This is necessary in order for datastore (pessimistic) transactions to lock rows correctly.

  • Added a new SequenceFactory: com.solarmetric.kodo.impl.jdbc.schema.ClassDBSequenceFactory which provides class sensitive table-based id sequences. To use the new sequence factory, existing sequence tables need to be dropped to be mapped to the differing table structure.

  • Added a table name option to com.solarmetric.kodo.impl.jdbc.schema.DBSequenceFactory to map sequences to. To set this option, add the option tableName=yourname to com.solarmetric.kodo.impl.jdbc.SequenceFactoryProperties property when configuring your PersistenceManagerFactory.

  • Persistent types can once again be enumerated by using the com.solarmetric.kodo.PersistentTypes property. This property is optional, but help to avoid classloader issues when deploying to an application server.

  Bugfixes

  • Fixed data caching plug-in to not enlist objects with can-cache=false when loading existing data from the database.

  • Fixed bug in metadata parsing algorithm that could cause classloader problems in application servers

  • Fixed SQLServerDictionary to work around SQLServer's issues with setting null BLOBs via PreparedStatement.setNull().

  • Datastore locking (i.e., pessimistic locking) is now supported for Sybase. Note that the connection property "BE_AS_JDBC_COMPLIANT_AS_POSSIBLE=true" must be set, either in the ConnectionURL or the ConnectionProperties properties. See the SybaseDictionary.java source file for more details. This requires the Sybase JDBC driver version 4.5 or higher.

  Notable changes

  • Removed the AutoReturnTimeout property. The Kodo pooling DataSource no longer reclaims expired connections.

2.4.0 -- 13 Dec 2002

• New features

  • Pre-release versions of plugins for SunONE Studio, NetBeans, Eclipse, and WebSphere Studio are now available. See the documentation on installation and usage instructions.

  • Kodo JDO Enterprise Edition and the Kodo JDO Performance Pack are now bundled with a cache plug-in that supports Tangosol Coherence cache products. See the datastore cache documentation for details.

  • Added evictAll(Class) and evictAll(Extent) method calls to PersistenceManagerImpl. These methods are useful for clearing often-updated objects in pooled PersistenceManager configurations.

  • Added the capability of loading ResultSet objects (or any other stream of data) into PersistenceCapable objects associated with a PersistenceManager via application-defined logic.

  • Added metadata extensions for specifying custom ClassMapping and FieldMapping values for particular classes and fields.

  • Added class-level metadata extension to exclude certain classes from the PersistenceManagerFactory cache.

  • Added property for configuring the how long to wait before testing connections that have been put into the pool.

  • Simplified the process of defining custom subclass indicator behavior.

  • When supported by the underlying JDBC driver, Kodo will now use PreparedStatements and batch updates whenever possible for very significant performance benefits. See the documentation for the com.solarmetric.kodo.impl.jdbc.UsePreparedStatements and com.solarmetric.kodo.impl.jdbc.UseBatchedStatements properties.

  • Inverse one-to-one mappings are now supported. The field can now reside on either table corresponding to the related objects. If both sides of an one-to-one are marked as having an inverse, one field should be designated as read-only to indicate to the system the owning class and table for the given relational field.

  • Logging is now done through the Apache commons project, which offers the ability to use an underlying logging mechanism, such as Apache Log4J, JDK 1.4's native logging, or simple file/stdout logging. It is now necessary to include the new jakarta-commons-logging-1.0.2.jar jar in the CLASSPATH. See the Logging chapter.

  • Added a pluggable SQLExecutionManager architecture, which allows the developer to override the mechanism by which SQL is issued to the database. See the documentation for the com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerClass property.

  • There is now an option to automatically refresh the database schema during runtime, allowing the developer to skip the schematool step. See the documentation for the com.solarmetric.kodo.impl.jdbc.SynchronizeSchema property.

  • Properties may be specified for a Driver with the com.solarmetric.kodo.ConnectionProperties property.

  • A javax.sql.DataSource may be specified in the kodo.ConnectionDriverName property, which will be customizable with bean-like enteries in the com.solarmetric.kodo.ConnectionProperties property.

  • The default transaction isolation for a JDBC connection can be overridden with the com.solarmetric.kodo.impl.jdbc.TransactionIsolation property.

  • Kodo JDO now distributes a single jar for both the enterprise and standard edition, as well as datacache and query extensions.

  • The rd-metadatatool can now be used to generate default JDO metadata for classes.

  • The rd-schemagen tool used for reverse mapping classes from a schema has now been tested with the following databases: Hypersonic SQL 7.1, SQLServer (MS Beta 2 JDBC driver), Sybase, Oracle (9.0.1 JDBC driver), DB2, Postgres (7.3 Beta 3 JDBC driver).

  Bugfixes

  • default-fetch-group="false" is now respected for fields that default to default-fetch-group="true".

  • Traversing orphaned relations in data cache now behaves in the same way as traversing orphaned db relations -- the invalid relation is set to null.

  • Changing a field to the same value as it was originally set to no longer constitutes dirtying that field. This means that subsequent flushes to the database will not necessarily re-write the same data.

  • Class loading is performed in accordance with section 12.5 of the JDO specification.

  Notable changes

  • The API for implementing a SequenceFactory has changed. See the API documentation for com.solarmetric.kodo.impl.jdbc.SequenceFactory.

  • Persistent types are no longer enumerated, either in the data store or in a property. Classes are now dynamically added upon class initialization, via the JDOImplHelper class registration process. The -register and -unregister options to schematool are no longer needed. The JDO_SCHEMA_METADATA table is no longer used and can be dropped.

2.3.4

• New features

  • The R&D schema generator can now accept a list of tables to generate.

  • The R&D reverse mapping tool has additional options for using foreign key names to generate relation names, generating primitive wrapper-type fields if a column is nullable, and allowing primary keys on many-to-many join tables.

• Bugfixes

  • Fixed problems with many-to-many relations between tables that use vertical inheritance.

  • Fixed bug in schematool that caused it to not generate primary key columns in subclass tables when using datastore identity + custom names + vertical inheritance.

  • Fixed serp library conflict between reverse mapping tool and main Kodo libraries.

  • Fixed a reverse mapping tool bug in which column names that conflicted with Java keywords would result in the generation of uncompilable Java classes.

  • Fixed problem that caused read-only flag to be ignored in many-to-many relations.

  • Multi-table inheritance deletes are now performed from the leaf table in the inheritance chain up to the base table. Inserts are performed from the base table down to the leaf. This supports the common referential integrity model of establishing a foreign key relation from inherited tables to their parent tables.

2.3.3

• New features

  • The R&D schema generator can now accept a list of tables to generate.

• Bugfixes

  • Fixed null-value="default" behavior.

  • Fixed bugs that prevented removal of map elements through the key set, entry set, and values collection.

  • Added more validation on static/final fields to metadata.

  • Fixed memory leak in serp regarding soft and weak collections backed by HashSets.

  • Multi-variable query issues resolved.

  • Fixed bug that could cause optimistic lock version numbers to be incremented before successful transaction commit.

  • The R&D reverse mapping tool now handles Oracle DATE columns correctly.

2.3.2

• New features

  • The new com.solarmetric.kodo.CacheReferenceSize property dictates a number of hard references to cached objects that the PersistenceManager will retain, in addition to its soft cache.

  • Added 'all' option to unregister action of schematool Ant task. This option allows all classes in the current persistent types list to be unregistered, regardless of whether or not those classes are currently in the classpath.

  • Added com.solarmetric.kodo.UseSoftTransactionCache to configure whether or not Kodo should maintain soft references to transactional items that have not been dirtied. This now defaults to false; previous versions of Kodo always used soft references for non-dirty transactional items.

• Bugfixes

  • The jdodoclet task no longer creates JDO metadata entries for final or static fields, or for transient fields that do not have a jdo:persistence-modifier tag.

  • The jdoc task no longer attempts to enhance classes that have already been enhannced.

  • Several default property values were being set improperly.

2.3.1

• New features

  • Smart proxies for set and map fields. Smart proxies better optimize database updates when persistent set and map fields are modified.

  • TCP, JMS-based distributed DataCache implementations.

  • All DataCache implementations now use an LRU cache with a configurable maximum size.

  • Customizable tracked instance proxies.

  • Alpha release of upcoming reverse mapping tool for creating persistent class definitions, metadata, and mapping extensions from an existing schema.

  • Cache object com.solarmetric.kodo.runtime.datacache.PMFactoryCache is now named com.solarmetric.kodo.runtime.datacache.plugins.LocalCache.

• Bugfixes

  • A Query with an unspecified filter defaults to a filter of "true", rather than "false".

  • A Query with an unspecified candidate Extent but a specified candidate Class will automatically create an Extent of the appropriate type with subclasses turned on.

  • Various bugs related to compiled queries with null arguments or no parameters have been resolved.

  • Various InstanceCallbacks interface bugs have been resolved.

  • Ant schematool and jdoc tasks deal with the Ant ClassLoader system better.

• Notable changes

  • Made GenericDicitonary.toSQL() and GenericDicitonary.fromSQL() methods final. Subclasses of GenericDictionary that must change the behavior of SQL generation or parsing should do so by overriding the appropriate xxxToSQL() or xxxFromSQL() methods instead. Note that the source for all our dictionary classes is now available in the Kodo JDO distribution.

2.3.0

• New features

  • JDO specification version 1.0 support.

  • Highly flexible multiple-table inheritance model now supported. See the multi-table class mapping documentation for details.

  • Support for large result sets when using any JDBC 2.0+ driver that supports ResultSets of type TYPE_SCROLL_INSENSITIVE. Return values from all Query.executeXXX() methods will be an instance of java.util.List, which can then be used for efficient random access.

  • DataCache API batches distributed updates, facilitating custom processing of distributed cache invalidation.

  • DataCache implementation loads data read from the data store into the cache as well as data being written to the data store.

  • JDBC back-end customizability is improved, allowing for custom field and class mappings and much finer-grained control of generated SQL.

  • Kodo JDO now supports extending JDOQL with custom tags. A number of default extensions, including substring searches and case-insensitive searches, are included by default with Kodo JDO. For more on this feature, see the query extensions documentation.

  • Support for IBM WebSphere, and other application servers that do not provide a TransactionManager though a JNDI lookup.

  • Source code release for various utility classes under the source/ directory.

  • Deprecated the srcDir attribute of jdoc and schematool: the nested fileset no longer needs to be relative to an absolute directory.

  • Added a new method to ExtentImpl that returns a list containing all objects described by the extent.

• Bugfixes

  • Resolved a problem with large (> 5000 bytes) BLOBs being stored in Oracle.

  • Fixed problem with compiled queries and null parameters returning empty result sets. Currently, when null parameters are used, prepared statements are bypassed and custom SQL is generated instead. In a future release, a new prepared statement that uses IS NULL will be generated on-the-fly.

2.2.5 May 6, 2002

• New features

  • The String serialization of ObjectIds.Id now uses a '-' as the delimiter, as the previous choice of the '#' made it difficult to use the serialization in a JSP without re-encoding it.

  • Released ant tasks for JDO enhancement, the SchemaTool, and an XDoclet task for generating .jdo metadata files from java source code comments.

  • Integration features for the upcoming JBuilder 7.

• Bugfixes

  • Fixed issue with managed transaction rollbacks. See bug #157 for details.

  • Fixed problem with prepared statements and in-memory queries. See bug #161 for details.

2.2.4 SP1 April 19, 2002

• Bugfixes

  • Resolved issues when using null parameters and compiled queries.

2.2.4 April 17, 2002

• New features

  • Support for java.math.BigInteger and java.math.BigDecimal

  • Added support for using packagename.jdo as the package's JDO metadata file, where "packagename" is the last section of the resource's package. E.g., a java class named com.solarmetric.mypackage.MyClass can now use a metadata file named mypackage.jdo.

  • Query.compile() will now create and use a PreparedStatement.

  • Kodo JDO now supports both single-JVM and distributed caching of persistent data.

  • It is now possible to extend the PersistenceManagerImpl and the EEPersistenceManager.

  • Added support for serialization/deserialization of an object id to/from a String.

  • Added an example of using Kodo within JSPs in the samples/jdo/jsp/ directory.

• Bugfixes

  • Resolved inefficient behavior when executing a query that returns objects that have already been loaded but are hollow (bug 116).

  • Fixed NotSerializableException when trying to bind an instance of EEPersistenceManagerFactory into JNDI (bug 117).

  • Fixed problem where changing any of the configuration values in a PersistenceManagerFactory changed those values for all PersistenceManagerFactory instances on the system (bug 131).

2.2.3 March 4, 2002

• New features

  • New and improved documentation is now available at docs/manual.html. Enjoy!

  • Added code to check parameter count against declared parameter count when executing queries.

  • Partial support for the Java Connector Architecture is now available in the Enterprise Edition. This permits simple configuration of Kodo JDO using an application server's JCA configuration tools.

  • PersistenceManagerFactory instances can now be created from a Properties.

  • Guaranteed that SQL statements corresponding to object modifications (insert, update, delete) occur in the order that the modifications were performed in the PersistenceManager. If an object is modified multiple times, it will remain in the position that it was in after its first modification. When committing, we now traverse this list in order, so it is possible to do things like delete an object and then add a new object with the same id in a single transaction.

  • Added optional '-outfile filename' option to schematool. If specified, the SQL statements necessary to perform the schema modification will be appended to filename. No changes will be made to the database itself. This is useful when database modification is not permitted, or for post-processing the SQL generated by Kodo JDO with an external tool.

  • Changed schematool to print a warning when an array, collection, or map field is implicitly made persistent because of the rules of the spec. This often leads to undesirable behavior, as the default mode of insertion is to serialize the array/collection/map into a BLOB field, which is more often than not the desired behavior.

  • Both 'kodo' and 'tt' are now supported vendor tags. No collision checking is performed, so you should probably use just one.

  • Added support for Hypersonic free file-based JDBC driver

  • Added a new database preference: db/schema-name. If set, this value will be used in calls to DatabaseMetaData.getTables().

• Bugfixes

  • Made queries take into account changes in the current transaction if IgnoreCache == false.

  • Made extents pay attention to changes made in the current transaction

  • Changed methods that are part of javax.jdo interfaces to never throw anything but JDOExceptions. See bug 69.

  • Resolved problem with listing table names when multiple database users should each have their own set of tables. See bug 77.

  • Only invalidate the connection and not return it to the pool if the Connection name contains "postgres". See PostgreSQL bugfix in 2.2.2 section for more details.

  • Fixed a problem where executing 'jdoc' on a package.jdo that contains both app id and datastore id classes causes a failure.

  • Improved error messages.

2.2.2 February 14, 2002

• New features

  • Added a duplicate column check to SQL INSERT and UPDATE query generation methods. If a duplicate column name is encountered and the values are also duplicates, then life proceeds happily along. If duplicates are found and the values differ, a JDOUserException is thrown. This permits using schema mappings in which a column is used both as a primary key and a foreign key.

• Bugfixes

  • Resolved potential deadlocks. See bug 42.

  • Added mechanism for controlling date precision when constructing SQL statements. See bug 6.

  • Fixed schematool strangeness when using table name metadata extensions. See bug 54.

  • improved error-reporting in exceptions thrown when invalid data is added to proxy collections/maps.

  • Fixed bug in which persistent-deleted objects were not containing the correct values on rollback if RetainValues was set. This fix makes persistent-deleted objects transition to hollow instead of performing any rollback.

  • Transaction.commit() and Transaction.rollback() now throw a JDOUserException instead of an IllegalStateException when a transaction is not active. See bug 44.

  • Because of a probable Postgres JDBC driver bug, changed connection pooling to not recycle connections that have been involved in a transaction.

  • Resolved a VerifyError that occurred when a non-primitive, non-String object was used as part of an object's primary key.

  • Resolved a situation in which the number of connections needed to load a single object from the data store was proportional to the depth of persistence-capable fields in the tree of default fetch groups. That is, if A has a relation to B called b, and B has a relation to C called c, and b is in A's default fetch group, and c is in B's default fetch group, then three connections were needed in order to load an A.

  • Fixed bug in which queries on date fields occasionally threw exceptions.

  • Fixed obscure bug in makeDirty(). If using data store transactions and setting a JDO field without first having loaded the field (either implicitly by having the field in the default fetch group, or explicitly), then the field would not be set when InstanceCallbacks.jdoPostLoad() was invoked. Additionally, nontransactionalRead must have been set to true for this problem to occur.

  • Fixed a bug that caused queries to fail in certain Tomcat configurations. See bug 35.

  • Added writeReplace() methods to fix issues with serialization of dates and collection types retrieved from data stores.

  • Fixed bug in which jdoNewInstance(StateManager,Object) method was only being added to base application identity classes.

  • com/solarmetric/kodo/runtime/PersistenceManagerImpl.java: improved error reporting when validating and making persistent objects that are not managed by the current PM.

• Notable changes

  • Made default table type for MySQL be Berkley DB, which has real transactional capabilities

  • Set the default to warn on persistent type failures, rather than throw an exception.

2.2.1 November 1 2001

• New features

  • IBM DB2 UDB 7.2 is now supported.

  • All datastore identity classes now use the com.solarmetric.kodo.util.ObjectIds.Id object ID type rather than individual dynamically loaded classes.

  • Performance enhancements.

• Bugfixes

  • Old versions of MySQL for Windows are now supported.

  • A new algorithm for auto-generation of table/column/index names that is much less likely to generate naming collisions is now available.

  • Fixed PersistenceManager.refreshAll() behavior when no transaction is active.

  • New persistent objects, first class children, etc. are correctly dealt with when created in jdoPreStore().

  • Queries that perform multiple contains(), containsKey(), or containsValue() clauses &&'d together for different values on the same collection/map now work.

  • The PM will throw some subclass of JDOFatalException on commit if and only if the transaction is also automatically rolled back.

• Notable changes

  • One-to-one mappings are dealt with more efficiently, reducing the number of database accesses and therefore improving performance.

  • Changed resource-loading and class-loading to use the current thread's context's class loader, rather than the system class loader. This makes deployment to a web application container much easier.

  • A single class is now used as the ID class for all persistent types managed with data store identity.

2.2.0 October 5, 2001

• New features

  • Application identity is now supported.

  • Preview release of tool to generate a class suitable for use as an application-identity object id class, complete with an appropriate equals() method, a corresponding hashCode() method, and a toString() method. For more information and usage, run 'java com.solarmetric.kodo.tools.appid.ApplicationIDTool'.

  • Improvements have been made to common error messages, and inappropriate exception types have been replaced with more useful ones.

  • New library: kodo-jdo-runtime.jar. This library contains all the class files necessary for run-time use of Kodo JDO.

  • Enhanced mapping customizations for mapping application-identity pk fields (see docs/existing-schema.html)

  • Various minor performance enhancements

• Bugfixes

  • PersistenceManager refresh methods behave correctly when invoked from outside the context of a transaction. Note that the noargs refreshAll () call behaves as designated by the JDO javadoc, not as designated by the 0.95 specification.

  • SQL generation for statements that insert decimals (floats and doubles) now always use United States notation (3.14159 for example).

  • Assorted minor bugfixes.

• Notable changes

  • Major redesign of the refresh mechanism.

beta 2.1 July 15, 2001

• New features

  • The null-value attribute on field metadata is supported.

  • BLOB mappings are supported; any serializable field can now be persisted. (Note: PostgreSQL does not support BLOB mappings)

• Bugfixes

  • jdoPreStore() is no longer called on deleted instances.

  • Fixed a NullPointerException that could occur when softly-cached instances were garbage collected by the JVM.

  • Indexes were not being created on fields marked with the 'column-index' metadata extension.

  • Fixed a bug that prevented retrieving CLOB values with Oracle.

  • Fixed a bug that caused a SQLException with fields set to empty strings or chars with a 0 value on PostgreSQL.

• Notable changes

  • The SQLTypeMap, used in DBDictionaries, changed slightly.

  • The Kodo User Guide chapter on Metadata has been updated to include information on the new 'blob' metadata extension for explicitly marking fields that should be stored in serialized form.

beta 2 July 10, 2001

• New features

  • Maps with user-defined persistent object values can be persisted (n-many relations).

  • Static inner classes can be persisted.

  • Queries support the use of containsKey() and containsValue() for Map fields.

  • Queries support ordering declarations.

  • The SchemaTool's schema migration capabilities have been enhanced.

  • The SchemaTool offers the option of automatically maintaining the list of persistent types for the system.

  • Schema generation can be customized through JDO metadata.

  • The standard javax.sql.DataSource is used to obtain connections.

  • Connection pooling has been enhanced, and new pooling parameters have been added (timeout time, autoreturn time).

  • The ObjectId helper class has been introduced to map opaque JDO OID values to and from primitive long values.

  • PersistenceManagerFactories can be stored in JNDI, including JNDI trees that are replicated over multiple JVMs.

  • PersistenceManagers can transparently synchronize with global J2EE Transactions (Kodo Enterprise Edition beta only).

• Bugfixes

  • Row-level locking is now performed within pessimistic Transactions.

  • Object ID generation is now done using the database by default.

  • Globally unique primary key values are no longer required (per-class only).

  • Inserting new instances of classes mapped to an existing schema without a class indicator column no longer throws a NullPointerException.

  • Numerous minor fixes.

• Notable changes

  • Users of previous beta versions of Kodo should scan the user guide in the docs/ directory for new information included with this release.

  • The schematool can now automatically maintain a list of persistent classes; the persistent-types array in system.prefs is not needed. This is covered in the Database Setup chapter of the user guide.

  • The syntax for using the schematool has changed. This is covered in the Database Setup chapter of the user guide.

  • The syntax for mapping classes to existing database tables has changed. This is covered in the Using Existing Schema chapter of the user guide.

  • The Runtime Use chapter of the user guide covers new runtime options available, such as JNDI storage of the JDBCPersistenceManagerFactory and safe conversion of JDO OID values to and from primitive long values.