I would like to have dynamic control over fetch groups at runtime. Is this possible?
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”.
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 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”.
How do I directly access the JDBC Connection that Kodo is using?
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”.
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.
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.
I would like to execute my queries in raw SQL rather than using JDOQL. Is this possible?
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.
How do I issue a query against a Date field?
You need to use a parameter to for the query. For details, see Section 11.2, “JDOQL”. An example of this is:
Example 1.1. Issuing a query against a Date field
Query query = myPersistenceManager.newQuery ("dateField < now"); query.declareParameters ("java.util.Date now"); Collection results = (Collection)query.execute (new Date ());
When is the object id available to be read when creating a new persistent instance?
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.
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. See Example 11.8, “Query By Example” for details on how this works.