Yes, using Kodo's custom fetch groups. To have complete control over the fields that are loaded when the persistent object is instantiated, you could declare each field as belonging to a different custom fetch group, and then at runtime set up the fields to be loaded for a specific operation. See Section 14.5, “Fetch Groups”.

There are a number of ways to decouple an instance from the PersistenceManager. The simplest is to just call makeTransient() on the object, which will decouple the object (but not related objects) from the PersistenceManager. If you want to decouple the object as well as all its relations, you can serialize the object and then deserialize it, but this will traverse the entire object graph, which could potentially draw down the entire contents of the database, with catastrophic memory and performance consequences. The third way is to use Kodo's attach and detach extensions, which allows an object and all those fields in the current fetch group for the object be detached (and then possibly serialized later). For information about detaching instances, see Section 11.1, “Detach and Attach”.

Kodo provides a number of ways to access the underlying JDBC connection that the PersistenceManager is using. See Section 4.9, “Runtime Access to JDBC Connections”.

Yes. You can enable the SQL logging channel to see all the SQL statements that are sent from the database. You can also enable the JDBC channel to see most of the JDBC operations (such as commit and rollback operations) that are exectued. For details on logging configuration, see Chapter 3, Logging.

Yes. Kodo has built-in support for Log4J and the Apache Commons Logging frameworks. In turn, the Commons Logging framework can be configured to use JDK 1.4 java.util.logging. Additionally, it is possible to plug in your own logging implementation to override Kodo's default behavior. For details on logging configuration, see Chapter 3, Logging.

Yes. Kodo allows you to directly execute SQL statements and have the results returned as instances of your persistent classes. See Section 13.4, “Direct SQL Execution”. This can be useful for migrating your queries from a JDBC application to a JDO application.

You need to use a parameter to for the query. For details, see Section 11.2, “JDOQL”. An example of this is:

Query query = myPersistenceManager.newQuery ("dateField < now");
query.declareParameters ("java.util.Date now");
Collection results = (Collection)query.execute (new Date ());

When you first ask for the object id (via JDOHelper.getObjectId or PersistenceManager.getObjectId), or on flush -- whatever happens first. In fact, if the identity of your object depends on auto-increment columns, asking for the object id can cause an implicit flush to get the database-generated primary key value(s).

Once you have flushed or retrieved the id of an object, that id is permanent. If the object uses application identity, attempting to change any primary key fields will cause an exception.

You can provide a template object for Kodo to compare to by using a non-persistent parameter to a query. See Example 11.8, “Query By Example” for details on how this works.