> 2. Spec updates JDO-749 "Support for java.time types, and querying using 
> associated methods" https://issues.apache.org/jira/browse/JDO-749
> 
> Chapter 14: why are other supported time types not orderable? 

No reason, I simply added LocalDateTime, LocalDate, LocalTime where Date was 
previously mentioned - this could become supported java.time types. But then 
there are other types not mentioned in that section that are supported as 
persistable (Locale, Calendar, etc), so why were they excluded?. 
Same applies in Result Class Requirements section.

> Chapter 18: why don't other supported time types not have default JDBC types?

Because the default still needs defining. To give an example
java.time.YearMonth can be persisted (by DN) as
* String
* DATE (setting day to 0)
* (INT, INT) storing the year and month.


> There is special treatment for Local time, date, and date time. Are there 
> implementation issues?

I see no implementation issue, and I also see no "special treatment" (in the 
spec). Where?


> 4. Other issues
> 
> There are several un-accepted changes in the specification noticed during 
> review of changes in JIRA issues. 

Do you mean "Track Changes" is ON in the spec docs in SVN? clearly, because the 
tracked changes in those docs are what has changed since 3.1 (so that it is 
easier to compile a list of changes when 3.2/4.0 is ever released). Or maybe 
you mean something else



When is there confirmation of what this release is to be called? I'm assuming 
3.2, but such a thing should be decided up front when the scope of changes is 
visible ... which it is.


Regards
-- 
Andy
DataNucleus (Web: http://www.datanucleus.org   Twitter: @datanucleus)

Reply via email to