Minutes: JDO TCK Conference Call Thursday October 5, 9:30 AM Pacific Daylight Time (PDT)

[Craig Russell]

Attendees: Michael Bouschen, Tilmann Zäschke, Craig Russell

Next meeting: October 31 9:30 AM Pacific

Agenda:

1. Release Policy Updates

2. JDO-770 "Switch from svn to git" 
https://issues.apache.org/jira/browse/JDO-770

3. JDO-652 "Provision of a typesafe refactor-friendly query capability for 
JDOQL" https://issues.apache.org/jira/browse/JDO-652

In order to run the tck tests for the fluent query, DataNucleus needs to be in 
the class path when compiling the test classes. The current patch includes this 
in the maven dependencies. But we also need to consider the case of IUT where 
the IUT classes need to be in the compile class path.

How to handle the query INTO and RESULT? 

If the RESULT is "new LongString((personid, lastname)" we need to specify the 
result class and the names of the fields as positional constructor parameters.

Similarly, if the INTO is "LongString.class" we need to specify the names of 
the fields to be mapped.

For both of these, we might add a parameter to the query.result method 
specifying the class of the result, e.g. LongString.class. Need to make sure 
this does not conflict with any other overloaded result method.

For mapping the field names we need to provide a list (array) of String to the 
query. e.g.:

query.ResultMapping(List) specifies name mapping for positional 
parameters of result constructors.

Or, we can add an "as" method to the query expression taking a String name of 
the field in the target and returning the expression. 

We have the same issue with orderBy with ASC, DESC.

4. Issues with Fix Version JDO-3.2 

5. JDO 3.1: Need to go through change lists in JIRA for 3.1 RC1 and 3.1 to 
prepare JCP Change Log
6. Other issues

Should avg() applied to BigDecimal really return Double?

Action Items from weeks past:
[Jan 18 2018] AI Craig talk to some git/svn Apache experts to get some advice. 
Specifically, how to preserve the svn history, how to manage the web site.
[Oct 30 2015] AI Craig: File a maintenance review with JCP
[Apr 17 2015] AI Craig: Oracle spec page on JDO need to be updated once the JCP 
Maintenance Release for JDO 3.1 is published
[Oct 17 2014] AI Matthew any updates for "Modify specification to address NoSQL 
datastores": https://issues.apache.org/jira/browse/JDO-651?
[Feb 28 2014] AI Everyone: take a look at 
https://issues.apache.org/jira/browse/JDO-712
[Feb 28 2014] AI Everyone: take a look at 
https://issues.apache.org/jira/browse/JDO-625
[Dec 13 2013] AI Craig file a JIRA for java.sql.Blob and java.sql.Clob as 
persistent field types
[Aug 24 2012] AI Craig update the JIRAs JDO-689 JDO-690 and JDO-692 about 
JDOHelper methods. In process.

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org  http://db.apache.org/jdo 

[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL

[Andy Jefferson (JIRA)]

[ 
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639607#comment-16639607
 ] 

Andy Jefferson commented on JDO-652:


If adding generics to the returned NumericExpression on those methods in 
NumericExpression, suggest that log, exp ought to be NumericExpression, 
certainly if cos, sin, tan etc are going to be.

As mentioned earlier, I would make the methods lt, gt, etc on 
ComparableExpression take in

{{ComparableExpression expr}}

rather than just ComparableExpression. Hard to see if you have this change 
given the number of patch files there

 

I have no particular preference on IfThenElse methods. What you have is fine by 
me.

 

Separate issue : in recent source control tools we don't need to faff about 
with patches; people can just have a separate branch to develop changes in and 
then it is immediately visible what the overall API is. Also developers don't 
need to leave their changes in separate files that others have to apply to be 
able to see them; the branch can be downloaded and ran directly without 
manipulation. Wouldn't that be a more convenient way of developing features? 
Then, when it is agreed, the changes are just applied to the master branch. FWIW

> Provision of a typesafe refactor-friendly query capability for JDOQL
> 
>
> Key: JDO-652
> URL: https://issues.apache.org/jira/browse/JDO-652
> Project: JDO
>  Issue Type: New Feature
>  Components: api, specification, tck
>Reporter: Andy Jefferson
>Assignee: Michael Bouschen
>Priority: Major
> Fix For: JDO 3.2
>
> Attachments: JDO-652-api-ifTheElse.txt, JDO-652-api-patch-Andy.txt, 
> JDO-652-patch4.txt, typesafe.patch, typesafe_manifest.patch
>
>
> There are various querying capabilities of this type around. JPA2 has its 
> Criteria query API. Third party solutions like QueryDSL also exist, in its 
> case providing a JDOQL implementation (as well as JPQL, and HQL). We should 
> seriously consider introducing something along these lines in the JDO2.4 
> timeframe. 
> There is a comparison of JPA Criteria with QueryDSL over at 
> http://source.mysema.com/forum/mvnforum/viewthread_thread,49



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)