Attendees: Michael Bouschen, Matthew Adams, Michelle Caisse, Erik
Bengtson, Craig Russell
Agenda:
1. Persistent interface specification clarification proposals
usage in pm.newInstance:
In order for the newInstance method to be used with a persistent
interface, the parameter interface must be completely mapped. That
is, the interface must be declared in metadata using the interface
element.
Additionally, for relational implementations,
o the interface must be mapped to a table; portable applications will
use the table attribute for this purpose
o all persistent properties must be mapped to columns; portable
applications will use the column attribute of the property element
contained in the interface element
o interfaces that are of types of relationships declared as
persistent properties of the parameter interface must all be
completely mapped
o to be portable, all implementations of persistent interfaces will
share a common concrete persistence-capable base class
If any of the above conditions is not met, JDOUserException is thrown
by the newInstance method.
note: a persistent interface should use the same rules as persistent
classes for deciding whether a property is persistent or not; the
generated class will contain proper implements of non-persistent
properties
usage in field type:
Metadata requirements for persistence-capable classes that implement or
use persistence-capable interfaces
Note PC classes that "java implement" pc interfaces don't even need
the implements clause of the metadata
For persistence-capable classes that implement persistence-capable
interfaces, if the persistence-capable class employs property-level
interception for the persistence-capable interface's property, or
if the
persistence-capable class employs field-level interception for the field
that stores the value of the persistence-capable interface's property
and the field's name and type matches the property's name and type, then
no additional metadata is required.
Query usage: If the persistence-capable class
employs field-level interception for the field that stores the value the
persistence-capable interface's property and the field's name or type
differs from the property's name or type, the "class" element must
include the "implements" element, which for each unmatched property and
field, must include a "property" element whose "name" attribute matches
the persistence-capable interface's property name and whose "field-name"
attribute is the name of the field that stores the value of the
persistence-capable interface's property.
For persistence-capable classes that contain a field or property of a
persistence-capable interface type, no additional metadata is
required. If the user wishes to restrict the type of instances that
can be stored in this field, the field-type attribute is used.
The application is portable if all implementations of the
persistence-capable interface share a common persistence-capable
superclass; if they do not, then the application is not portable.
The inclusion of the "property" element within the "implements" element
is primarily intended to support query filter expressions that traverse
fields of interface types.
AI: All review Matthew's examples
usage in query:
If the metadata for a persistence-capable interface indicates (via
the explicit or implicit setting of the requires-extent attribute)
that an extent is managed for the interface, then the extent consists
of the datastore objects of the persistence-capable classes
implementing the interface including the datastore objects created
with PersistenceManager.newInstance.
The candidate class of a JDOQL query may be a persistence-capable
interface. In this case the candidate class name scope includes the
persistent properties as explicitly or implicitly defined as
persistent properties in the metadata of the persistence-capable
interface.
JDOQL supports navigation through a field or property of the type of
a persistence-capable interface. Such an expression may then be
further decomposed in order to access persistent properties.
Another remark:
Section18.3 ELEMENT interface says: "The requires-extent attribute is
optional. If set to "false", the JDO implementation does not need to
support extents of factory-made persistent instances."
I understand that "factory-made persistent instances" refers to
instances created by PM.newInstance. Then I propose to remove
"factory-made", because the extent of a persistence-capable interface
may consist of the extents of the persistence-capable classes
implementing the interface and then there are no "factory-made"
persistence instances are involved.
interface requires-extent means that an extent of factory-made
instances is managed and getExtent can be executed on the interface.
The extent of the interface includes all factor-made instances plus
all instances of pc classes that both implement the interface and
manage an extent.
Note that if an interface is defined as "detachable" then the
implementation must generate a Serializable class for the interface.
AI Craig: Formalize the above concepts and send to community for review.
2. Forking codeline for JDK 1.5 support: Planning on forking api2-
legacy "now". Next week we will change the JIRA for 1.5 support.
groupId, artifactId, versionId for these projects
3. JDOHelper enhancements: AI Matthew: send proposal
4. Callback annotations: AI Matthew: send proposal
5. Groovy integrations: AI Matthew: send proposal
6. Other issues
Action Items from weeks past:
[Aug 11 2006] AI Craig propose some semantics for behavior if user
tries to add to a list where the ordering element is incorrect.
[Jul 14 2006] AI: Erik document 220 annotations that don't have a
corresponding JDO concept.
[Jun 23 2006] AI Martin look at what Hibernate and TopLink support
for Enum types. In progress.
[Apr 14 2006] AI Craig: update the roadmap for JDO. In progress.
[Nov 4 2005] AI Martin: Update Martin's wiki with discusion of JDK
1.5 issues. In progress
[Sep 2 2005] AI: To recruit members, update the web site. Articles
on TheServerSide directing attention to the site. T-shirts, logo.
AI: Craig write a ServerSide article.
-- Michelle
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!