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, Oct 23 9 am PDT
Date Fri, 23 Oct 2009 16:57:57 GMT
Attendees: Michelle Caisse, Craig Russell

Agenda:

1. Change JTA 1.1 dependency artifact id from "transaction-api" to  
"jta" https://issues.apache.org/jira/browse/JDO-644

Seems innocuous enough. Probably should not change legacy projects  
since we have no plans to ship them.

2. Query timeout test https://issues.apache.org/jira/browse/JDO-623

Erik replied to the discussion, and we need to continue to discuss on  
email.

3.  tck enhancement should make use of feature to enhance an entire  
directory https://issues.apache.org/jira/browse/JDO-639

Patch looks good.

4. Run TCK using Maven2 for consistency  https://issues.apache.org/jira/browse/JDO-647

5. Select new build/project tool  https://issues.apache.org/jira/browse/JDO-632 
  - Close it for lack of volunteers?

See item 4 above. We're looking for someone who can spend some quality  
time changing the tck2 build/test process to use maven2. The maven.xml  
is pretty complex and it's not a simple task. Seems like the biggest  
challenge is to learn enough about maven2 to be able to map the  
features of the tck2 maven.xml to plugin functionality.

6. runtime2 project fails to compile https://issues.apache.org/jira/browse/JDO-648

Assigned to Michelle (thanks).

7. Query objects and hashCode()  + equals() request from Jörg:

> it would be nice if the spec would mandate that implementations of
> javax.jdo.Query do correctly implement hashCode() and equals().
>
> Alternatively, Query.toString() could be required to return the
> single-string representation of the query, or some dedicated method  
> was
> added to provide it.
>
> This would make it easier to e.g. implement some custom cache for  
> query
> results, or, more generally, it would make it easier to put Query
> objects as keys into Maps.

As users execute mutator methods on queries, the string representation  
would change. And the contract for hashCode and equals is that they  
are immutable (for proper use in sets or map keys). So I don't see how  
we can mandate that hashCode and equals rely in any internal state.

Having the single-string version of a query is useful but adds  
implementation complexity. While there is a requirement for an  
implementation to parse a single string query into executable form,  
there's no current requirement to create the single string form from  
the internal form.

It appears to me that if you want this functionality at the  
application framework layer, then the framework can mandate that the  
single string form be used and at the time the query is created, the  
single string form be used as the key into a framework map.

8. Other issues

Michelle is still investigating query timeouts as they apply to SQL  
standard datastores.

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message