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 ());

It depends on several factors. If you invoke JDOHelper.getObjectId() on your object during the course of a transaction, you will get the object id as of the beginning of the transaction. If you invoke JDOHelper.getTransactionalObjectId(), you'll get the most up-to-date object id.

If you're using application identity, then the PK values are populated when you populate them, and the object-id object itself is created upon a call to makePersistent(). If you populate the application id PK fields after the makePersistent() call, then the return from JDOHelper.getObjectId() will be a temporary id, and the return from JDOHelper.getTransactionalObjectId() will be the most up-to-date id.

If you're using datastore identity, then it depends on how the PK is generated. Basically, unless you're using auto-increment columns (see Example 5.5, “Auto-Increment Object Ids”) then Kodo will generate/get the PK upon the call to makePersistent(). This is one of the reasons that we don't recommend using auto-increment columns, since that reduces our ability to do batching and a couple other things.

It is guaranteed that JDOHelper.getTransactionalObjectId() will return the permanent id by the time the current transaction has flushed. This includes manual KodoPersistenceManager.flush() invocations as well as automatic incremental flushes or commits.

It is also guaranteed that JDOHelper.getObjectId() will return the permanent id by the time the current transaction has committed.