[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=15616051#comment-15616051
]
Tilmann Zäschke commented on JDO-735:
-
In theory, I could imagine that a database server process could benefit from a
{{close()}} method. While {{closeAll()}} releases all resources associated with
a specific query, {{close()}} could serve as a hint to the server that no
similar query is expected to be executed in the near future. This may allow the
server to drop resources such as index pages that were only used for that
query.
This would not necessarily require support for {{isClosed()}} (unusable state),
because a user could still be allowed to use the query later on.
The most resources are probably associated with query results, not queries.
Therefore, an alternative may be to make query results AutoCloseable. This
would require queries (such as the new JDOQLTypedQuery) to return something
like a {{CloseableList}} when executed.
> 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: Minutes: JDO TCK Conference Call Friday October 28, 9 AM Pacific Daylight Time (PDT)
> 1. New JIRA JDO-757 "Add @Repeatable to all annotations which can be > repeated" https://issues.apache.org/jira/browse/JDO-757 > > Looks like we are almost done here. No need to deprecate existing “repeatable > container” annotations. If any user really wants to use them, fine. Well there would be zero point in deprecating them since they are required for @Repeatable to work, hence they can never be deleted. > Question: > why was ElementType.TYPE added to Column? What does this mean? Means that when @Column annotation was originally added it was incorrect. @Column on a class is to define "unmapped columns" to equate to just under in XML. When adding @Repeatable the compiler tells you about such errors so had to be fixed (so that the singular annotation with @Repeatable is consistent with the container annotation). Regards -- Andy DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
[jira] [Closed] (JDO-757) Add @Repeatable to all annotations which can be repeated
[
https://issues.apache.org/jira/browse/JDO-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Jefferson closed JDO-757.
--
Resolution: Fixed
test applied to SVN
> Add @Repeatable to all annotations which can be repeated
>
>
> Key: JDO-757
> URL: https://issues.apache.org/jira/browse/JDO-757
> Project: JDO
> Issue Type: Improvement
> Components: api
>Reporter: Andy Jefferson
>Assignee: Andy Jefferson
> Fix For: JDO 3.2
>
> Attachments: jdo-757-test.patch
>
>
> Since JDO 3.2 is for a minimum of Java 8, we can make annotations more usable
> by adding @Repeatable so that instead of
> @Extensions({@Extension(vendorName="datanucleus",key="option1",value="val"),@Extension(vendorName="datanucleus",key="option2",value="val")})
> the user can specify
> @Extension(vendorName="datanucleus", key="option1", value="val")
> @Extension(vendorName="datanucleus", key="option2", value="val")
> This should be done to all annotations that have an associated plural with
> "value" attribute
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JDO-758) What can a subquery return?
Tilmann Zäschke created JDO-758:
---
Summary: 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)
