db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: JDO TCK Conference Call Friday, Feb 23, 9 am PST
Date Fri, 23 Feb 2007 19:24:06 GMT
Attendees: Michael Bouschen, Matthew Adams, Michelle Caisse, Erik  
Bengtson, Craig Russell


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  

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  

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  

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!

View raw message