[jira] [Commented] (JDO-735) Make PersistenceManager and Query support AutoCloseable (JDK1.7+)
[ https://issues.apache.org/jira/browse/JDO-735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15637513#comment-15637513 ] Craig L Russell commented on JDO-735: - There are several competing interests here: 1. Dissuade programmers from using close(). They should use closeAll() instead. With autocomplete in their Java IDE, when they start to type clos they should get javadoc which should say "don't use this method; use closeAll instead". 2. If programmers accidentally use close() they should have to catch Exception, which is the only method in JDO that throws Exception. So we need to either *not* declare close() in the interfaces or declare close() with the throws Exception clause. 3. If we declare void close() throws Exception and say its semantics are identical to closeAll(), users might think "If semantics are identical, why does close() throw Exception and closeAll() does not"? The best solution seems to be: Declare (override) void close() throws Exception in the Query and Extent interfaces. Provide javadoc that says "don't use this method. It is intended for use by try-with-resources. Use closeAll() instead." > Make PersistenceManager and Query support AutoCloseable (JDK1.7+) > - > > Key: JDO-735 > URL: https://issues.apache.org/jira/browse/JDO-735 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Andy Jefferson >Assignee: Michael Bouschen > Fix For: JDO 3.2 > > Attachments: CloseWithActiveTxRollsBack.java > > > So then it can be used with JDK1.7+ try-with-resources, as per > http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: JDO TCK Conference Call Friday November 4, 9 AM Pacific Daylight Time (PDT)
Attendees: Tilmann Zäschke, Craig Russell NOTE: Next week phone call is canceled. Next meeting Nov 18 9 AM PST. Agenda: 1. New JIRA JDO-758 "What can a subquery return?" https://issues.apache.org/jira/browse/JDO-758 Subqueries that return anything but aggregates are not required to be supported. AI Craig update specification p. 183 and 193 for clarity. 2. JDO-757 "Add @Repeatable to all annotations which can be repeated" https://issues.apache.org/jira/browse/JDO-757 Done. 3. JDO-751 "Support for Java8 Optional" https://issues.apache.org/jira/browse/JDO-751 Need to review the specification changes and approve/reject. 4. JDO-735 "Make PersistenceManager and Query support AutoCloseable (JDK1.7+)" https://issues.apache.org/jira/browse/JDO-735 One last issue: do we include close() in the declaration? This may help tooling that shows javadoc. Tentative conclusion: include close() throws Exception with javadoc saying don’t use this method; it’s only for try-with-resources. AI Craig update JIRA 5. JDO-747 "Behavior of delete() with multiple concurrent Transactions" https://issues.apache.org/jira/browse/JDO-747 6. JDO 3.1: Need to go through change lists in JIRA for 3.1 RC1 and 3.1 to prepare JCP Change Log 7. Other issues Action Items from weeks past: [Oct 30 2015] AI Craig: File a maintenance review with JCP [May 15 2015] AI Craig Spec change for roll back an active transaction when closing a persistence manager (JDO-735) [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 Architect craig.russ...@oracle.com P.S. A good JDO? O, Gasp!
[jira] [Updated] (JDO-758) What can a subquery return?
[
https://issues.apache.org/jira/browse/JDO-758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Bouschen updated JDO-758:
-
Affects Version/s: JDO 3.1
Fix Version/s: JDO 3.2
Component/s: specification
> What can a subquery return?
> ---
>
> Key: JDO-758
> URL: https://issues.apache.org/jira/browse/JDO-758
> Project: JDO
> Issue Type: Improvement
> Components: specification
>Affects Versions: JDO 3.1
>Reporter: Tilmann Zäschke
>Priority: Minor
> Fix For: JDO 3.2
>
>
> The current spec specifies that subqueries should support ordering and
> grouping, suggesting that subqueries should be able to return collections of
> results.
> However, a Java {{Collection}} (others are not supported in JDOQL) only
> support {{size()}}, {{isEmpty()}} and {{contains()}}. These three functions
> all return scalars, furthermore, these could all be implemented easily with
> an additional term inside the subquery. Since the current reference
> implementation does not support all these functions, it should be considered
> whether subqueries should at all be required to return collections of objects.
> A similar argument could be made for returning persistent objects from
> subqueries (suggested by required support for 'unique'). Persistent objects
> cannot be used in the parent query, except for accessing their identity, or
> possibly casting them to a persistent type and access a field.
> Can anyone think of a usecase or other argument why subqueries should be able
> to return anything else than scalars/boolean (and possibly single persistent
> objects)?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JDO-758) What can a subquery return?
[
https://issues.apache.org/jira/browse/JDO-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15636889#comment-15636889
]
Craig L Russell commented on JDO-758:
-
Well, size() is not needed because the subquery can include COUNT.
And isEmpty() is not needed because the subquery can include Selecgt(COUNT...)
== 0.
And contains(...) is not needed because the subquery could include the object
id that you would compare to.
I vote to require only aggregates in subqueries. And no method calls on results
of subqueries.
> What can a subquery return?
> ---
>
> Key: JDO-758
> URL: https://issues.apache.org/jira/browse/JDO-758
> Project: JDO
> Issue Type: Improvement
>Reporter: Tilmann Zäschke
>Priority: Minor
>
> The current spec specifies that subqueries should support ordering and
> grouping, suggesting that subqueries should be able to return collections of
> results.
> However, a Java {{Collection}} (others are not supported in JDOQL) only
> support {{size()}}, {{isEmpty()}} and {{contains()}}. These three functions
> all return scalars, furthermore, these could all be implemented easily with
> an additional term inside the subquery. Since the current reference
> implementation does not support all these functions, it should be considered
> whether subqueries should at all be required to return collections of objects.
> A similar argument could be made for returning persistent objects from
> subqueries (suggested by required support for 'unique'). Persistent objects
> cannot be used in the parent query, except for accessing their identity, or
> possibly casting them to a persistent type and access a field.
> Can anyone think of a usecase or other argument why subqueries should be able
> to return anything else than scalars/boolean (and possibly single persistent
> objects)?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
