3.1.6 -- August 25, 2004

• Notable Changes

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

• Bugfixes

  • Fixed bug with metadata MappingFactory and XDoclet generated metadata with horizontal mappings.

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 B.6, “Firebird”.

  • Borland Interbase is now a supported database. See Section B.1, “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. See Section 1.14, “XML Store Manager”.

  • The Kodo workbench now includes a live JDOQL query executor and result browser. See Section 2.7.6, “JDOQLEditor” and Chapter 8, JDOQL Editor.

• 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 10.9, “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 14.10, “Data Cache Eviction Through the Persistence Manager”.

  • 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 10.9, “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.3, “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.0RC2 -- March 24, 2004

• New features

  • Added the ability to use remote persistence managers over HTTP/HTTPS. See Chapter 11, Remote and Offline JDO 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 Worbench 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.2, “Automatic Runtime 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. See Section 7.6.4, “Horizontal Inheritance Mapping” for details.

  • Added the ability to use Kodo from remote client machines communicating with a persistence manager server. See Section 11.2, “Remote Persistence 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 14.6, “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 7.6.3.3, “Vertical Query Modes” for details.

  • Sigificantly improved technology preview of Kodo Management / Monitoring capability based on JMX. Includes local and remote management functions, management of Datastore 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.5.2, “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. See Section 11.1.3, “Detach and Attach Callbacks”.

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

  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.3, “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 8.4, “The SQLLine Utility”, and for complete documentation, see http://sqlline.sourceforge.net.

  • Added support for expressing nested O/R mapping extensions via XDoclet. See Section 15.3, “XDoclet” for details.

  • Introduced a cache for shareable query-related information. This improves query compilation times in many situations. See Section 2.6.37, “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 14.3.2, “Kodo JDO Cache Usage” 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.RetainValuesInOptimistic flag to true 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 Section 13.3, “Direct SQL Execution” 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 13.4, “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 datastore 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 14.3.7, “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.RetainValuesInOptimistic configuration property to true. 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, false);
    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 the Query Aggregates and Projections documentation for more 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/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. See the section on SQL Statement Ordering & Foreign Keys for more information.

  • 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. See the section on Primary Key Generation for more information.

  • 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 Appendix D: 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 javax.jdo.option.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/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.