Yes, using custom fetch groups, or simply by adding the fields you want fetched to Kodo's internal fetch plan. See Section 5.6, “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 JDO's attach and detach APIs, which allows an object to be detached (and then possibly serialized later). For information about detaching instances, see Section 8.7, “Detach and Attach Functionality”.

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. You can execute queries in raw SQL and get the results back as either persistent objects, value arrays, or data structs.

For executing SQL queries through the JPA, see Chapter 11, SQL Queries.

For executing SQL queries through the JDO API, see Chapter 17, SQL Queries.

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

Query query = pm.newQuery (Magazine.class, "publishedDate < :now");
List results = (List) query.execute (new Date ());

When you first ask for the object id (via standard APIs or by reading a primary key field), 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 in JDO.