Attendees: Matthew Adams, Michael Bouschen, Craig Russell Agenda: 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 none Craig 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:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! |
smime.p7s
Description: S/MIME cryptographic signature
