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 Minutes: JDO TCK Conference Call Friday, Nov 2, 9 am PST
Date Fri, 03 Nov 2006 17:57:19 GMT
Attendees: Matthew Adams, Michael Bouschen, Craig Russell


1. Date arithmetic in queries: There are at least two different  
issues here:

1a. Retrieving the date from the server. In Oracle, you can SELECT  
CURRENT_DATE FROM DUAL. In JDOQL, we have no special persistent class  
that has a singleton, to request that exactly one element is  
returned. We could use void.class, or null as the candidate class, or  
JDOHelper, or PersistenceManagerFactory. The query would look like  
"Select xxx From void". Another way to handle this would be to add an  
API to PersistenceManagerFactory, e.g. Xxx currentDate().

1b. Using the date in the WHERE clause. Most of the interesting  
methods on Date have been deprecated in favor of Calendar. We could  
use Calendar.getInstance() which would return the instance in the  
time zone and locale of the server. We can support comparisons of  
this Calendar with fields of type Date. In order to support date  
arithmetic, we could use the add(int field, int amount) method to  
change various fields. For portability, we should specify which  
calendar fields must be supported by an implementation, e.g.  
Calendar.DAY_OF_MONTH. An issue is that the signature of add returns  
void. So you can't use the result of add for anything. I suppose we  
could follow the example of StringBuffer and have the result of add  
be a Calendar, returning this. Similarly, methods roll, set, setTime,  
setTimeInMillis, getTime, and getTimeInMillis might be considered as  
required or optional. This should depend on the common functionality  
of database back ends for the required methods, and implementations  
could choose to add more supported methods.

If the candidate collection is an extent or the result of an extent  
query, then the Calendar functionality refers to the database back  
end. If the candidate collection is a collection, then it refers to  
the VM.

2.  New subprojects for JDK 1.5 support: There are two ways to  
distinguish the artifacts. One is to use a different artifact id; the  
other is to use a different version number. The projects that need  
different content are the api20 and tck20 projects. These probably  
will be branched for the different artifacts. The trunk should  
continue with the jdk15 support; the earlier support would be branched.

3. Other issues



Action Items from weeks past:

[Oct 27 2006]  AI: Matthew add comment to JDO-403 regarding split  
between JDO and ORM annotations..

[Sep 1 2006] AI Craig  check into default handling to accommodate  
different defaults for annotations (?) based  on context. In progress.

[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