I want to decouple a persistent instance from its
PersistenceManager and
Transaction. How can I do this?

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”.

1.4.3.

Can I see the SQL that Kodo is issuing to the database?

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.

1.4.4.

Can Kodo use my existing logging framework instead of its own?

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.

1.4.5.

I would like to execute my queries in raw SQL.
Is this possible?

Yes. You can execute queries in raw SQL and get the results
back as either persistent objects, value arrays, or data
structs.

When is the object id available to be read when creating a
new persistent instance?

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.

1.4.8.

How do I do query-by-example in Kodo?

You can provide a template object for Kodo to compare to
by using a non-persistent parameter to a query.