[jira] [Comment Edited] (JDO-822) Verify compatibility with JDK 21
[ https://issues.apache.org/jira/browse/JDO-822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780029#comment-17780029 ] Andy Jefferson edited comment on JDO-822 at 11/1/23 7:58 AM: - FYI, DataNucleus v6.0.6 has latest ASM (v9.6), so supports up to and including Java 22. Plugins needed for TCK are (minimum) datanucleus-core 6.0.6, datanucleus-api-jdo 6.0.1, datanucleus-api-jpa 6.0.1, datanucleus-rdbms 6.0.6 See [https://github.com/datanucleus/datanucleus-core/issues/495] and [https://github.com/datanucleus/datanucleus-core/issues/499] was (Author: andy): FYI, DataNucleus GitHub master (unreleased) has latest ASM, so should "support" Java 21. https://github.com/datanucleus/datanucleus-core/issues/495 > Verify compatibility with JDK 21 > > > Key: JDO-822 > URL: https://issues.apache.org/jira/browse/JDO-822 > Project: JDO > Issue Type: Task > Components: api, tck >Affects Versions: JDO 3.2.1 >Reporter: Tilmann Zäschke >Priority: Major > Fix For: JDO 3.2.2 > > > JDK 21 reached [General > Availability|https://openjdk.org/projects/jdk8/milestones#General_Availability] > on 19 September 2023, so we should go for JDK 21 instaed of JDK 20. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JDO-822) Verify compatibility with JDK 21
[ https://issues.apache.org/jira/browse/JDO-822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780029#comment-17780029 ] Andy Jefferson commented on JDO-822: FYI, DataNucleus GitHub master (unreleased) has latest ASM, so should "support" Java 21. https://github.com/datanucleus/datanucleus-core/issues/495 > Verify compatibility with JDK 21 > > > Key: JDO-822 > URL: https://issues.apache.org/jira/browse/JDO-822 > Project: JDO > Issue Type: Task > Components: api, tck >Affects Versions: JDO 3.2.1 >Reporter: Tilmann Zäschke >Priority: Major > > JDK 21 reached [General > Availability|https://openjdk.org/projects/jdk8/milestones#General_Availability] > on 19 September 2023, so we should go for JDK 21 instaed of JDK 20. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JDO-812) Move to JDK 11 as the lowest supported version
[
https://issues.apache.org/jira/browse/JDO-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17558863#comment-17558863
]
Andy Jefferson commented on JDO-812:
FWIW DataNucleus v6.0 moved to supporting Java 11+ only, and is now released.
Oracle Premier support for Java 8 ended in March 2022, even if their extended
support continues.
DataNucleus (v6) has some use of things like List.of, or '@Generated' (which
moved package for some reason from Java 8 -> 9 hence forced the move for us)
but doesn't yet define modules or much else.
> Move to JDK 11 as the lowest supported version
> --
>
> Key: JDO-812
> URL: https://issues.apache.org/jira/browse/JDO-812
> Project: JDO
> Issue Type: Task
> Components: api, site and infrastructure, tck
>Affects Versions: JDO 3.2.1
>Reporter: Tobias Bouschen
>Priority: Minor
> Fix For: JDO 3.3
>
>
> I propose to move the lowest supported JDK version to JDK11 to allow us to
> move the used libraries (like Derby) to the newest version. Additionally,
> this would allow us to use some of the comfort features that were introduced
> in-between JDK 8 and 11 (like In-line Collection creation through
> {{{}List.of(...){}}}, etc.).
> From what I remember, we should already be fully compatible with JDK 11, so
> the switch itself should only require minimal effort.
> This would definitely be a breaking change, so the benefit of this change
> would have to be considered under this aspect as well (if we don't already
> have breaking changes since 3.2). A second consideration would also be when
> the next release is likely to take place (and whether JDK 8 will still be
> relevant at that point.)
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (JDO-809) Mapping info for ArrayListCollections/TreeSetCollections doesn't correctly map embedded element fields
[ https://issues.apache.org/jira/browse/JDO-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson resolved JDO-809. Assignee: Andy Jefferson Resolution: Fixed Fixed by commit https://github.com/apache/db-jdo/commit/c2ae74ab0b393786962106961d291d2254ba531c > Mapping info for ArrayListCollections/TreeSetCollections doesn't correctly > map embedded element fields > -- > > Key: JDO-809 > URL: https://issues.apache.org/jira/browse/JDO-809 > Project: JDO > Issue Type: Bug > Components: tck >Affects Versions: JDO 2 final (2.0), JDO 3 (3.0), JDO 3.1, JDO 3.2 >Reporter: Andy Jefferson >Assignee: Andy Jefferson >Priority: Major > Fix For: JDO 3.2.1 > > > The tests for the different java.util.Collection types all should follow the > same pattern, with the samples having a range of fields that cover the > primary field usages. > Field XXXOfObject1 should represent a Collection of Object, where the Object > is a PersistenceCapable type, persisting embedded into a join table. > Field XXXOfSimpleClass should represent a Collection of PersistenceCapable > type, persisting embedded into a join table. > Field XXXOfSimpleInterface should represent a Collection of interface, where > the interface is a PersistenceCapable type, persisting embedded into a join > table. > > In the case of the ArrayList and TreeSet cases the ORM files do not define > the block for how the fields of the PersistenceCapable element > will map into the join table. The schema for those cases also do not map the > fields of the PersistenceCapable element, instead just having a FK to the > table of the element (so not embedded at all). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JDO-809) Mapping info for ArrayListCollections/TreeSetCollections doesn't correctly map embedded element fields
[ https://issues.apache.org/jira/browse/JDO-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515741#comment-17515741 ] Andy Jefferson commented on JDO-809: See GitHub pull request #42 > Mapping info for ArrayListCollections/TreeSetCollections doesn't correctly > map embedded element fields > -- > > Key: JDO-809 > URL: https://issues.apache.org/jira/browse/JDO-809 > Project: JDO > Issue Type: Bug > Components: tck >Affects Versions: JDO 2 final (2.0), JDO 3 (3.0), JDO 3.1, JDO 3.2 >Reporter: Andy Jefferson >Priority: Major > > The tests for the different java.util.Collection types all should follow the > same pattern, with the samples having a range of fields that cover the > primary field usages. > Field XXXOfObject1 should represent a Collection of Object, where the Object > is a PersistenceCapable type, persisting embedded into a join table. > Field XXXOfSimpleClass should represent a Collection of PersistenceCapable > type, persisting embedded into a join table. > Field XXXOfSimpleInterface should represent a Collection of interface, where > the interface is a PersistenceCapable type, persisting embedded into a join > table. > > In the case of the ArrayList and TreeSet cases the ORM files do not define > the block for how the fields of the PersistenceCapable element > will map into the join table. The schema for those cases also do not map the > fields of the PersistenceCapable element, instead just having a FK to the > table of the element (so not embedded at all). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (JDO-809) Mapping info for ArrayListCollections/TreeSetCollections doesn't correctly map embedded element fields
Andy Jefferson created JDO-809: -- Summary: Mapping info for ArrayListCollections/TreeSetCollections doesn't correctly map embedded element fields Key: JDO-809 URL: https://issues.apache.org/jira/browse/JDO-809 Project: JDO Issue Type: Bug Components: tck Affects Versions: JDO 3.2, JDO 3.1, JDO 3 (3.0), JDO 2 final (2.0) Reporter: Andy Jefferson The tests for the different java.util.Collection types all should follow the same pattern, with the samples having a range of fields that cover the primary field usages. Field XXXOfObject1 should represent a Collection of Object, where the Object is a PersistenceCapable type, persisting embedded into a join table. Field XXXOfSimpleClass should represent a Collection of PersistenceCapable type, persisting embedded into a join table. Field XXXOfSimpleInterface should represent a Collection of interface, where the interface is a PersistenceCapable type, persisting embedded into a join table. In the case of the ArrayList and TreeSet cases the ORM files do not define the block for how the fields of the PersistenceCapable element will map into the join table. The schema for those cases also do not map the fields of the PersistenceCapable element, instead just having a FK to the table of the element (so not embedded at all). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JDO-806) Use apache URL for schemaLocation of JDO XSDs
[
https://issues.apache.org/jira/browse/JDO-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17513216#comment-17513216
]
Andy Jefferson commented on JDO-806:
Just a question why we (currently) have XSD XMLNS for a jdo XML file as
{{http://xmlns.jcp.org/xml/ns/jdo/jdo"}}
{{ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"}}
{{ xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/jdo/jdo
https://db.apache.org/jdo/xmlns/jdo_3_2.xsd; version="3.2">}}
and not
{{https://db.apache.org/jdo/xmlns/jdo"}}
{{ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"}}
{{ xsi:schemaLocation="https://db.apache.org/jdo/xmlns/jdo
https://db.apache.org/jdo/xmlns/jdo_3_2.xsd; version="3.2">}}
It seemingly makes no difference to XML validation in an IDE (e.g Eclipse), but
why burden the user with having to think where to put xmlns.jcp.org (that this
API doesn't use, nor is maintained) and where to put db.apache.org ?
For reference, Jakarta Persistence uses jakarta.ee for XMLNS as well as
xsi:schemaLocation
> Use apache URL for schemaLocation of JDO XSDs
> -
>
> Key: JDO-806
> URL: https://issues.apache.org/jira/browse/JDO-806
> Project: JDO
> Issue Type: Improvement
> Components: api
>Affects Versions: JDO 3.2
>Reporter: Michael Bouschen
>Priority: Major
> Fix For: JDO 3.3
>
>
> In JDO 3.2 the schemaLocation of JDO XSDs link to
> [http://xmlns.jcp.org/xml/ns/jdo/] where is one of jdo_3_2.xsd,
> jdoconfig_3_2.xsd, jdoquery_3_2.xsd, orm_3_2.xsd. It seems that the site
> [http://xmlns.jcp.org/xml/ns] is not updated anymore, so it is unlikely that
> the 3.2 XSDs are available under this URL (see JDO-744).
> One idea ist might be to switch to an Apache URL, where we can control the
> download sites.
> This change requires corresponding changes to the specification, api, and
> tck. Here is a proposed plan to implement:
> # Update the xsds and dtds in the api/resources to change the headers.
> # Update the xsds and dtds in the db.apache.org/jdo/xmlns with the changes.
> # Update the xsds and dtds in the tck with the changes. This step will fail
> without a corresponding change to the reference implementation.
> # Update the specification with the changes. A partial list of affected
> sections:
> ## 11.1.4 p. 122
> ## 18.24 p. 261
> ## 18.25 p. 265
> ## 18.26 p. 287, 298
> ## New C.23 Changes since 3.2 p. 404
> Open question: should we keep the version number of the xsd and dtd files as
> 3.2 even though the api, tck, and specification will be updated to 3.2.1? I
> would say yes, and only change the version number of the files if there is a
> change to the content of the xsd and/or dtd.
> My proposal is: the 3.2.1 version of JDO would still refer to the 3.2 version
> of the xsd and dtd.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (JDO-806) Use apache URL for schemaLocation of JDO XSDs
[ https://issues.apache.org/jira/browse/JDO-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17512445#comment-17512445 ] Andy Jefferson commented on JDO-806: Missing jdoconfig.xsd, jdoconfig.dtd ? > Use apache URL for schemaLocation of JDO XSDs > - > > Key: JDO-806 > URL: https://issues.apache.org/jira/browse/JDO-806 > Project: JDO > Issue Type: Improvement > Components: api >Affects Versions: JDO 3.2 >Reporter: Michael Bouschen >Priority: Major > Fix For: JDO 3.3 > > > In JDO 3.2 the schemaLocation of JDO XSDs link to > http://xmlns.jcp.org/xml/ns/jdo/ where is one of jdo_3_2.xsd, > jdoconfig_3_2.xsd, jdoquery_3_2.xsd, orm_3_2.xsd. It seems that the site > [http://xmlns.jcp.org/xml/ns] is not updated anymore, so it is unlikely that > the 3.2 XSDs are available under this URL (see JDO-744). > One idea ist might be to switch to an Apache URL, where we can control the > download sites. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JDO-807) Update schema descriptor of JDO Metadata file to use latest 3.2 xsd definition
[ https://issues.apache.org/jira/browse/JDO-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510346#comment-17510346 ] Andy Jefferson commented on JDO-807: DataNucleus always uses a local copy when we have configured the precise XML file "identity" to map to an internal XSD/DTD. See [https://github.com/datanucleus/datanucleus-api-jdo/blob/master/src/main/resources/plugin.xml#L132] The apache URLs aren't added in DataNucleus code yet, so you will likely get issues if you change your XML file across to using that before then > Update schema descriptor of JDO Metadata file to use latest 3.2 xsd definition > -- > > Key: JDO-807 > URL: https://issues.apache.org/jira/browse/JDO-807 > Project: JDO > Issue Type: Task > Components: api, tck >Affects Versions: JDO 3.2 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.3 > > > Most of the JDO metadata files (.jdo, .jdoquery, .orm) use the 3.0 schema > descrpitor: > http://java.sun.com/xml/ns/jdo/jdo; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xsi:schemaLocation="http://java.sun.com/xml/ns/jdo/jdo > [http://java.sun.com/xml/ns/jdo/jdo_3_0.xsd];> > This should be updated to use the 3.2 version: > .jdo-files: > http://xmlns.jcp.org/xml/ns/jdo/jdo; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/jdo/jdo > [http://xmlns.jcp.org/xml/ns/jdo/jdo_3_2.xsd];> > .orm-files: > http://xmlns.jcp.org/xml/ns/jdo/orm; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/jdo/orm > [http://xmlns.jcp.org/xml/ns/jdo/orm_3_2.xsd];> > .jdoquery-files > http://xmlns.jcp.org/xml/ns/jdo/jdoquery; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/jdo/jdoquery > [http://xmlns.jcp.org/xml/ns/jdo/jdoquery_3_2.xsd];> -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JDO-807) Update schema descriptor of JDO Metadata file to use latest 3.2 xsd definition
[ https://issues.apache.org/jira/browse/JDO-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509989#comment-17509989 ] Andy Jefferson commented on JDO-807: Doesn't [JDO-806|https://issues.apache.org/jira/projects/JDO/issues/JDO-806?filter=allopenissues] need doing first, and then they can be changed to use the apache URL. > Update schema descriptor of JDO Metadata file to use latest 3.2 xsd definition > -- > > Key: JDO-807 > URL: https://issues.apache.org/jira/browse/JDO-807 > Project: JDO > Issue Type: Task > Components: api, tck >Affects Versions: JDO 3.2 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.3 > > > Most of the JDO metadata files (.jdo, .jdoquery, .orm) use the 3.0scheema > descrpitor: > http://java.sun.com/xml/ns/jdo/jdo; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xsi:schemaLocation="http://java.sun.com/xml/ns/jdo/jdo > [http://java.sun.com/xml/ns/jdo/jdo_3_0.xsd];> > This should be updated to use the 3.2 version: > .jdo-files: > http://xmlns.jcp.org/xml/ns/jdo/jdo; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/jdo/jdo > [http://xmlns.jcp.org/xml/ns/jdo/jdo_3_2.xsd];> > .orm-files: > http://xmlns.jcp.org/xml/ns/jdo/orm; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/jdo/orm > http://xmlns.jcp.org/xml/ns/jdo/orm_3_2.xsd;> > .jdoquery-files > http://xmlns.jcp.org/xml/ns/jdo/jdoquery; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/jdo/jdoquery > http://xmlns.jcp.org/xml/ns/jdo/jdoquery_3_2.xsd;> -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JDO-806) Use apache URL for schemaLocation of JDO XSDs
[ https://issues.apache.org/jira/browse/JDO-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491428#comment-17491428 ] Andy Jefferson commented on JDO-806: +1 on using an Apache URL; Jakarta specs use jakarta.ee URLs, and besides anything that removes dependencies on Oracle has always been a good thing ... > Use apache URL for schemaLocation of JDO XSDs > - > > Key: JDO-806 > URL: https://issues.apache.org/jira/browse/JDO-806 > Project: JDO > Issue Type: Improvement > Components: api >Affects Versions: JDO 3.2 >Reporter: Michael Bouschen >Priority: Major > > In JDO 3.2 the schemaLocation of JDO XSDs link to > http://xmlns.jcp.org/xml/ns/jdo/ where is one of jdo_3_2.xsd, > jdoconfig_3_2.xsd, jdoquery_3_2.xsd, orm_3_2.xsd. It seems that the site > [http://xmlns.jcp.org/xml/ns] is not updated anymore, so it is unlikely that > the 3.2 XSDs are available under this URL (see JDO-744). > One idea ist might be to switch to an Apache URL, where we can control the > download sites. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JDO-744) XSD/DTD not published for JDO 3.1
[
https://issues.apache.org/jira/browse/JDO-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479185#comment-17479185
]
Andy Jefferson commented on JDO-744:
Can we make sure that this is done for the v3.2 variants also, at release?
People can't be advised to include
"{{{}http://xmlns.jcp.org/xml/ns/jdo/jdo_3_2.xsd;
{}}}
in their XML file when it doesnt exist.{{{}{}}}
> XSD/DTD not published for JDO 3.1
> -
>
> Key: JDO-744
> URL: https://issues.apache.org/jira/browse/JDO-744
> Project: JDO
> Issue Type: Bug
> Components: api
>Affects Versions: JDO 3.1
>Reporter: Andy Jefferson
>Assignee: Craig L Russell
>Priority: Major
> Fix For: JDO 3.2
>
>
> Should be on
> http://xmlns.jcp.org/xml/ns/jdo/jdo_3_1.xsd
> http://xmlns.jcp.org/dtd/jdo_3_1.dtd
> No idea how they are to get on that private server. Perhaps someone knows?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (JDO-796) Write TCK test case to test JTA assertions
[ https://issues.apache.org/jira/browse/JDO-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17413017#comment-17413017 ] Andy Jefferson commented on JDO-796: FYI, DataNucleus has some (largely contributed) tests for JTA specifics, particularly UserTransaction usage. To be found under [https://github.com/datanucleus/tests/tree/master/jdo/jta] This makes use of a stand-alone JTA, in this case [JOTM|https://jotm.ow2.org/]. > Write TCK test case to test JTA assertions > -- > > Key: JDO-796 > URL: https://issues.apache.org/jira/browse/JDO-796 > Project: JDO > Issue Type: Task > Components: tck >Affects Versions: JDO 3.1 >Reporter: Michael Bouschen >Priority: Major > > Need test cases for assertions A16.1.3-1, A16.1.3-2 and A16.1.3-3 (see > chapter 16). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JDO-782) Initially deferred constraint should be removed from BaseDatastoreAdapter instead of child classes
[ https://issues.apache.org/jira/browse/JDO-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson closed JDO-782. -- Resolution: Invalid Nothing to do with the Apache JDO project > Initially deferred constraint should be removed from BaseDatastoreAdapter > instead of child classes > -- > > Key: JDO-782 > URL: https://issues.apache.org/jira/browse/JDO-782 > Project: JDO > Issue Type: Improvement >Reporter: László Bodor >Priority: Major > > It seems like only Oracle supports initially deferred constraints, so it > would make sense to remove it from BaseDatastoreAdapter instead of removing > it from every single subclass, and adding it only to OracleAdapter. > My original issue was that Datanucleus generated initially deferred > constraints for MariaDB because it used BaseDatastoreAdapter. However, maybe > it makes sense to create a MariaDbAdapter (which inherits from Mysql), there > is another way to fix that (proposed above) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (JDO-781) ForeignKey constructor should be called with consistent initiallyDeferred value
[
https://issues.apache.org/jira/browse/JDO-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Jefferson closed JDO-781.
--
Resolution: Invalid
Nothing to do with the Apache JDO project
> ForeignKey constructor should be called with consistent initiallyDeferred
> value
> ---
>
> Key: JDO-781
> URL: https://issues.apache.org/jira/browse/JDO-781
> Project: JDO
> Issue Type: Improvement
>Reporter: László Bodor
>Priority: Major
>
> https://github.com/datanucleus/datanucleus-rdbms/blob/master/src/main/java/org/datanucleus/store/rdbms/table/TableUtils.java#L131
> {code}
> ForeignKey fk = new ForeignKey(fieldMapping, storeMgr.getDatastoreAdapter(),
> referencedTable, true);
> {code}
> as we have reference here for the datastore adapter, initiallyDeferred=true
> parameter could be changed to:
> {code}
> storeMgr.getDatastoreAdapter().supportsOption(DatastoreAdapter.DEFERRED_CONSTRAINTS)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17360014#comment-17360014 ] Andy Jefferson commented on JDO-709: Good. Ignore the last comment on attributeName, of course I put "converter" on the Key, Value and Element annotations, so we don't need that anyway. > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Craig L Russell >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch > > > This request is to standardize a user's ability to specify conversions of > fields or properties of persistence-capable classes. Currently, this is left > to vendor extensions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17359994#comment-17359994 ] Andy Jefferson edited comment on JDO-709 at 6/9/21, 11:44 AM: -- The other use of the "attributeName" was when wanting to define a converter for the key/value of a Map (attributeName="key", or attributeName="value"), or when we have a Collection of some non-persistable element and wanting to define a converter for the element type. That could be of use, and DataNucleus has the code for it ... but it *would* require the Converts annotation if the user is providing "key" *and* "value" converters. So we could add the attributeName to the Convert annotation just for those 3 specific cases, but ignore the embedded field converter override. Whether it's worth the effort at this point is arguable, not so highly used was (Author: andy): The other use of the "attributeName" was when wanting to define a converter for the key/value of a Map (attributeName="key", or attributeName="value"), or when we have a Collection of some non-persistable element and wanting to define a converter for the element type. That could be of use, and DataNucleus has the code for it ... but it does not require the Converts annotation though. So we could add the attributeName to the Convert annotation just for those 3 specific cases, but ignore the embedded field converter override. > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Craig L Russell >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch > > > This request is to standardize a user's ability to specify conversions of > fields or properties of persistence-capable classes. Currently, this is left > to vendor extensions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17359994#comment-17359994 ] Andy Jefferson commented on JDO-709: The other use of the "attributeName" was when wanting to define a converter for the key/value of a Map (attributeName="key", or attributeName="value"), or when we have a Collection of some non-persistable element and wanting to define a converter for the element type. That could be of use, and DataNucleus has the code for it ... but it does not require the Converts annotation though. So we could add the attributeName to the Convert annotation just for those 3 specific cases, but ignore the embedded field converter override. > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Craig L Russell >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch > > > This request is to standardize a user's ability to specify conversions of > fields or properties of persistence-capable classes. Currently, this is left > to vendor extensions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17359853#comment-17359853 ] Andy Jefferson commented on JDO-709: [~clr] Yes, the "attributeName" was omitted when it was added in 2015; can't remember why. Easiest option is just to remove "Converts" and move forward, and maybe add a javadoc comment (to the Convert annotation that an attribute could be added if wanting to support overriding the specification of converters for fields of embedded objects) or just add a Jira issue for a future release. But then I'm not exactly so much in favour of using annotations for such things; I've never had a need to override a default converter for a field, defined on the embedded class; the JDO XML definition is way more expressive to achieve that (IMHO) > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Craig L Russell >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch > > > This request is to standardize a user's ability to specify conversions of > fields or properties of persistence-capable classes. Currently, this is left > to vendor extensions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JDO-794) Remove @Persistent field annotation in PCRectStringAnnotated
[ https://issues.apache.org/jira/browse/JDO-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352661#comment-17352661 ] Andy Jefferson commented on JDO-794: https://repo1.maven.org/maven2/org/datanucleus/datanucleus-api-jdo/5.2.7/ > Remove @Persistent field annotation in PCRectStringAnnotated > > > Key: JDO-794 > URL: https://issues.apache.org/jira/browse/JDO-794 > Project: JDO > Issue Type: Improvement > Components: tck >Affects Versions: JDO 3.2 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.2 > > > Remove the @Persistent annotation of fields upperLeft and lowerRight as soon > as datanuclues releases a version including fix for "Specifying @Convert > doesn't default to making a field persistent" > [https://github.com/datanucleus/datanucleus-api-jdo/issues/111]. The fix will > be released with version 5.2.7 of datanucleus-api-jdo. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JDO-709) Standardize field/property converters
[ https://issues.apache.org/jira/browse/JDO-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17341813#comment-17341813 ] Andy Jefferson commented on JDO-709: A "converted class" doesn't track changes *unless* the provider happens to have a wrapper class for that type. There is no obligation on a JDO provider to provide a wrapper for all possible types that a user may want to convert. Fields of a "converted class" are not declared using metadata; the user simply provides a converter that does the conversion for that type. > Standardize field/property converters > - > > Key: JDO-709 > URL: https://issues.apache.org/jira/browse/JDO-709 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Matthew T. Adams >Assignee: Craig L Russell >Priority: Minor > Labels: converstion, converter, jdo, type, type-converter > Fix For: JDO 3.2 > > Attachments: JDO-709-01.patch, JDO-709-3.patch, JDO-709-4.patch > > > This request is to standardize a user's ability to specify conversions of > fields or properties of persistence-capable classes. Currently, this is left > to vendor extensions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JDO-779) Migrate JDO Homepage / Online Documentation
[ https://issues.apache.org/jira/browse/JDO-779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080357#comment-17080357 ] Andy Jefferson commented on JDO-779: Well done on getting the web site migration going. Some comments in case you want to take them on board. # All pages currently seem to have artifacts in the "title" of the page, shown on the browser tab page name, like # Why do all pages have the Apache JDO logo plus Java Data Objects image? Makes perfect sense to have it on the main entry page, but you have the header area for common things. # Menu options could do with making more compact. e.g JDO Usage has "Implementations" ... put that under the previous menu, and indeed put I'd probably put the whole "JDO Implementation" items under "General". # "JDO Usage" menu option could be merged into a guide for using JDO rather than having a series of small pages like now. See the DN docs for say v5.2 for an example. There is a "guide" for Mapping, and a guide for "Persistence" and so on ... and just bundle all pages into a document. The whole point of having the (right hand) side options was to allow to navigate through a document, so if you have that enabled, then make your doc pages a document with a lot more in them, rather than a series of small pages (where no side navigation would be needed). If you do this then the "JDO Usage" menu will have way fewer items and be much more manageable. Hope that helps > Migrate JDO Homepage / Online Documentation > --- > > Key: JDO-779 > URL: https://issues.apache.org/jira/browse/JDO-779 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Reporter: Tilmann Zäschke >Assignee: Tilmann Zäschke >Priority: Major > > The homepage and online documentation is currently generated from xdoc (Maven > 1 doc format), located in the SVN 'site' repo. Te homepage and documentation > should be migrated to a more modern format, such as markdown, and moved to a > new repo. > Initial investigation: > * The only xdoc converter I found is > [Doxia|http://maven.apache.org/doxia/doxia-tools/doxia-converter/]. I don't > really know all the output formats, but one option may by (x)html. This maybe > useful because there exist many html to markdown converters. > * If we use 'html' as intermediate stage, it probably makes sense to > directly migrate the html version of the home page to markdown. > * There are many thml to markdown converters, such as [this PHP command line > converter|https://github.com/thephpleague/html-to-markdown]. > TODO: > # Decide on target repo and create it. Consensus appears to be to set up a > separate git repo, such as 'db-jdo-site'. Where do other projectys host their > website code? > # Decide on conversion path and target format (html -> markdown seems fine) > # Migration -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (JDO-779) Migrate JDO Homepage / Online Documentation
[ https://issues.apache.org/jira/browse/JDO-779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16835545#comment-16835545 ] Andy Jefferson edited comment on JDO-779 at 5/9/19 6:18 AM: FWIW DataNucleus uses Asciidoc / Asciidoctor to generate it's documentation. See [http://www.datanucleus.org:15080/products/accessplatform_5_2/] See [https://asciidoctor.org/docs/user-manual/] That operates on Asciidoc files (see [https://github.com/datanucleus/docs-accessplatform/tree/master/src/main/asciidoc] for examples of this format), has a Maven plugin, and generates HTML(5) and/or PDF (as well as other things if you want to go there). Many other Apache projects use that (e.g ISIS, TomEE). was (Author: andy): FWIW DataNucleus uses Asciidoc / Asciidoctor to generate it's documentation. See [http://www.datanucleus.org:15080/products/accessplatform_5_2/] See [https://asciidoctor.org/docs/user-manual/] That operates on Asciidoc files (but maybe also allows input of Markdown?), has a Maven plugin, and generates HTML and/or PDF (as well as other things if you want to go there). Many other Apache projects use that (e.g ISIS, TomEE). > Migrate JDO Homepage / Online Documentation > --- > > Key: JDO-779 > URL: https://issues.apache.org/jira/browse/JDO-779 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Reporter: Tilmann Zäschke >Assignee: Tilmann Zäschke >Priority: Major > > The homepage and online documentation is currently generated from xdoc (Maven > 1 doc format), located in the SVN 'site' repo. Te homepage and documentation > should be migrated to a more modern format, such as markdown, and moved to a > new repo. > Initial investigation: > * The only xdoc converter I found is > [Doxia|http://maven.apache.org/doxia/doxia-tools/doxia-converter/]. I don't > really know all the output formats, but one option may by (x)html. This maybe > useful because there exist many html to markdown converters. > * If we use 'html' as intermediate stage, it probably makes sense to > directly migrate the html version of the home page to markdown. > * There are many thml to markdown converters, such as [this PHP command line > converter|https://github.com/thephpleague/html-to-markdown]. > TODO: > # Decide on target repo and create it. Consensus appears to be to set up a > separate git repo, such as 'db-jdo-site'. Where do other projectys host their > website code? > # Decide on conversion path and target format (html -> markdown seems fine) > # Migration -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (JDO-779) Migrate JDO Homepage / Online Documentation
[ https://issues.apache.org/jira/browse/JDO-779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16835545#comment-16835545 ] Andy Jefferson edited comment on JDO-779 at 5/8/19 5:06 PM: FWIW DataNucleus uses Asciidoc / Asciidoctor to generate it's documentation. See [http://www.datanucleus.org:15080/products/accessplatform_5_2/] See [https://asciidoctor.org/docs/user-manual/] That operates on Asciidoc files (but maybe also allows input of Markdown?), has a Maven plugin, and generates HTML and/or PDF (as well as other things if you want to go there). Many other Apache projects use that (e.g ISIS, TomEE). was (Author: andy): FWIW DataNucleus uses Asciidoc / Asciidoctor to generate it's documentation. See [http://www.datanucleus.org:15080/products/accessplatform_5_2/] See [https://asciidoctor.org/docs/user-manual/] That operates on Markdown files, has a Maven plugin, and generates HTML and/or PDF (as well as other things if you want to go there). Many other Apache projects use that (e.g ISIS, TomEE). > Migrate JDO Homepage / Online Documentation > --- > > Key: JDO-779 > URL: https://issues.apache.org/jira/browse/JDO-779 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Reporter: Tilmann Zäschke >Assignee: Tilmann Zäschke >Priority: Major > > The homepage and online documentation is currently generated from xdoc (Maven > 1 doc format), located in the SVN 'site' repo. Te homepage and documentation > should be migrated to a more modern format, such as markdown, and moved to a > new repo. > Initial investigation: > * The only xdoc converter I found is > [Doxia|http://maven.apache.org/doxia/doxia-tools/doxia-converter/]. I don't > really know all the output formats, but one option may by (x)html. This maybe > useful because there exist many html to markdown converters. > * If we use 'html' as intermediate stage, it probably makes sense to > directly migrate the html version of the home page to markdown. > * There are many thml to markdown converters, such as [this PHP command line > converter|https://github.com/thephpleague/html-to-markdown]. > TODO: > # Decide on target repo and create it. Consensus appears to be to set up a > separate git repo, such as 'db-jdo-site'. Where do other projectys host their > website code? > # Decide on conversion path and target format (html -> markdown seems fine) > # Migration -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JDO-779) Migrate JDO Homepage / Online Documentation
[ https://issues.apache.org/jira/browse/JDO-779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16835545#comment-16835545 ] Andy Jefferson commented on JDO-779: FWIW DataNucleus uses Asciidoc / Asciidoctor to generate it's documentation. See [http://www.datanucleus.org:15080/products/accessplatform_5_2/] See [https://asciidoctor.org/docs/user-manual/] That operates on Markdown files, has a Maven plugin, and generates HTML and/or PDF (as well as other things if you want to go there). Many other Apache projects use that (e.g ISIS, TomEE). > Migrate JDO Homepage / Online Documentation > --- > > Key: JDO-779 > URL: https://issues.apache.org/jira/browse/JDO-779 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Reporter: Tilmann Zäschke >Assignee: Tilmann Zäschke >Priority: Major > > The homepage and online documentation is currently generated from xdoc (Maven > 1 doc format), located in the SVN 'site' repo. Te homepage and documentation > should be migrated to a more modern format, such as markdown, and moved to a > new repo. > Initial investigation: > * The only xdoc converter I found is > [Doxia|http://maven.apache.org/doxia/doxia-tools/doxia-converter/]. I don't > really know all the output formats, but one option may by (x)html. This maybe > useful because there exist many html to markdown converters. > * If we use 'html' as intermediate stage, it probably makes sense to > directly migrate the html version of the home page to markdown. > * There are many thml to markdown converters, such as [this PHP command line > converter|https://github.com/thephpleague/html-to-markdown]. > TODO: > # Decide on target repo and create it. Consensus appears to be to set up a > separate git repo, such as 'db-jdo-site'. Where do other projectys host their > website code? > # Decide on conversion path and target format (html -> markdown seems fine) > # Migration -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JDO-778) Adding overloaded methods to JDOQLTypedQuery to create a correlated subquery
[
https://issues.apache.org/jira/browse/JDO-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16793391#comment-16793391
]
Andy Jefferson commented on JDO-778:
No objections to these methods. If wanting these methods in DataNucleus the
simplest way is to provide a PR to
[https://github.com/datanucleus/datanucleus-api-jdo]
> Adding overloaded methods to JDOQLTypedQuery to create a correlated subquery
> -
>
> Key: JDO-778
> URL: https://issues.apache.org/jira/browse/JDO-778
> Project: JDO
> Issue Type: Improvement
> Components: api
>Affects Versions: JDO 3.1
>Reporter: Michael Bouschen
>Priority: Critical
> Fix For: JDO 3.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I propose to add the following overloaded subquery methods to support
> correlated subqueries using a relationship field of the from clause of the
> subquery, e.g.
> select firstname from org.apache.jdo.tck.pc.company.Employee
> where this.weeklyhours >
> (select AVG(e.weeklyhours) from this.department.employees e where
> e.manager == this.manager)
> {{<{color:#20999d}E{color}> JDOQLTypedSubquery<{color:#20999d}E{color}>
> subquery(CollectionExpression,
> {color:#20999d}E{color}> candidateCollection, String candidateAlias);}}
> {{<{color:#20999d}E{color}> JDOQLTypedSubquery<{color:#20999d}E{color}>
> subquery(ListExpression,
> {color:#20999d}E{color}> candidateList, String candidateAlias);}}
> {{<{color:#20999d}K{color}, {color:#20999d}V{color}>
> JDOQLTypedSubquery {color:#20999d}V{color}>> subquery(MapExpression {color:#20999d}V{color}>, {color:#20999d}K{color}, {color:#20999d}V{color}>
> candidateMap, String candidateAlias);}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16788992#comment-16788992 ] Andy Jefferson edited comment on JDO-652 at 3/10/19 6:00 PM: - If you get problems then you need to look in the LOG. It will tell you what the equivalent JDOQL string form is for a JDOQLTyped query, and it will also have a block about "QueryCompilation". That should be the same as the equivalent JDOQL string based query. That is where your debug starts. Then the log tells you the SQL invoked, for the single-string case and for the JDOQLTyped case. Should be the same if you have the same query. was (Author: andy): If you get problems then you need to look in the LOG. It will tell you what the equivalent JDOQL string form is for a JDOQLTyped query, and it will also have a block about "QueryCompilation". That should be the same as the equivalent JDOQL string based query. That is where your debug starts > 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)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16788992#comment-16788992 ] Andy Jefferson commented on JDO-652: If you get problems then you need to look in the LOG. It will tell you what the equivalent JDOQL string form is for a JDOQLTyped query, and it will also have a block about "QueryCompilation". That should be the same as the equivalent JDOQL string based query. That is where your debug starts > 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)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786479#comment-16786479 ] Andy Jefferson commented on JDO-652: See https://github.com/datanucleus/datanucleus-api-jdo/issues/97 > 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)
[jira] [Commented] (JDO-770) Switch from svn to git
[ https://issues.apache.org/jira/browse/JDO-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16783610#comment-16783610 ] Andy Jefferson commented on JDO-770: The GitHub commit messages now seem to go to *jdo-dev* mailing list, instead of to *jdo-commits* mailing list. Is this intentional? if so then suggest that somebody removes the *jdo-commits* list since it serves no further purpose. If not intentional then suggest that *jdo-commits* is used for commits. For reference Apache ISIS has an *isis-dev* and *isis-commits* and seem to have such messages split out. > Switch from svn to git > -- > > Key: JDO-770 > URL: https://issues.apache.org/jira/browse/JDO-770 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Affects Versions: JDO 3.1 >Reporter: Michael Bouschen >Assignee: Craig L Russell >Priority: Major > Fix For: JDO 3.2 > > > We should consider switching from svn to git. The reason to make jdo > available via git is to remove a possible barrier to new contributors. > There are several alternatives if we decide to offer git as an alternative to > svn: > * migrating all the code to git > * creating a read-only git mirror > * creating a read-write bridge. > See [Git at Apache | https://git.apache.org/] for more details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JDO-770) Switch from svn to git
[ https://issues.apache.org/jira/browse/JDO-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16783083#comment-16783083 ] Andy Jefferson commented on JDO-770: Why is the website not on GitHub under a simple "website" directory? Then people can commit updates to the website from the same source code host (and then have to do the manual update of the website). Better still would be (to do the above and then) for someone to enquire at Apache if it is possible to do auto-publishing of a website from a GitHub directory, e.g by running a cron job on some Apache box to build and publish the website. I've been doing this for years with DataNucleus and it means I never have to faff about with publishing, just commit the docs updates into GitHub and they appear on the website overnight. Further to that, and in reply to the Wiki question, has anyone looked at that Wiki in years? It is totally out of date. Users, in general, don't contribute to Wikis; we abandoned the DataNucleus one a few years back, and just encouraged people to provide GitHub pull requests to the docs. One less thing to maintain that way. > Switch from svn to git > -- > > Key: JDO-770 > URL: https://issues.apache.org/jira/browse/JDO-770 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Affects Versions: JDO 3.1 >Reporter: Michael Bouschen >Assignee: Craig L Russell >Priority: Major > Fix For: JDO 3.2 > > > We should consider switching from svn to git. The reason to make jdo > available via git is to remove a possible barrier to new contributors. > There are several alternatives if we decide to offer git as an alternative to > svn: > * migrating all the code to git > * creating a read-only git mirror > * creating a read-write bridge. > See [Git at Apache | https://git.apache.org/] for more details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JDO-770) Switch from svn to git
[ https://issues.apache.org/jira/browse/JDO-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774404#comment-16774404 ] Andy Jefferson commented on JDO-770: Comments : * I don't seem to have commit access to this, and all (past) commits of mine aren't linked to my GitHub account (andyjefferson). * Default branch should be "master", for consistency with every other project * URL is wrong on [https://github.com/apache/db-jdo/tree/master] > Switch from svn to git > -- > > Key: JDO-770 > URL: https://issues.apache.org/jira/browse/JDO-770 > Project: JDO > Issue Type: Improvement > Components: site and infrastructure >Affects Versions: JDO 3.1 >Reporter: Michael Bouschen >Assignee: Craig L Russell >Priority: Major > Fix For: JDO 3.2 > > > We should consider switching from svn to git. The reason to make jdo > available via git is to remove a possible barrier to new contributors. > There are several alternatives if we decide to offer git as an alternative to > svn: > * migrating all the code to git > * creating a read-only git mirror > * creating a read-write bridge. > See [Git at Apache | https://git.apache.org/] for more details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676364#comment-16676364
]
Andy Jefferson edited comment on JDO-652 at 11/6/18 8:53 AM:
-
The problem with that remaining test is simply the difference between
BigDecimal(1.1) and BigDecimal("1.1").
You pass in BigDecimal(1.1) and it is represented as a Literal with that value.
When the SQL is formed the literal has toString() called on it, hence on the
BigDecimal, and it comes across as
1.100088817841970012523233890533447265625. This doesn't crop up
with single-string JDOQL since the string is embodied directly, so is parsed to
a BigDecimal with that String as input.
Workaround is to change your ifThenElse line to use the following arguments
cand.budget.mul(new BigDecimal("1.2"))
cand.budget.mul(new BigDecimal("1.1"))
hence equivalent BigDecimal literals to the string form. Passes for me if that
change is made.
was (Author: andy):
The problem with that remaining test is simply the different between
BigDecimal(1.1) and BigDecimal("1.1").
You pass in BigDecimal(1.1) and it is represented as a Literal with that value.
When the SQL is formed the literal has toString() called on it, hence on the
BigDecimal, and it comes across as
1.100088817841970012523233890533447265625. This doesn't crop up
with single-string JDOQL since the string is embodied directly, so is parsed to
a BigDecimal with that String as input.
Workaround is to change your ifThenElse line to use the following arguments
cand.budget.mul(new BigDecimal("1.2"))
cand.budget.mul(new BigDecimal("1.1"))
hence equivalent BigDecimal literals to the string form. Passes for me if that
change is made.
> 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)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676364#comment-16676364
]
Andy Jefferson commented on JDO-652:
The problem with that remaining test is simply the different between
BigDecimal(1.1) and BigDecimal("1.1").
You pass in BigDecimal(1.1) and it is represented as a Literal with that value.
When the SQL is formed the literal has toString() called on it, hence on the
BigDecimal, and it comes across as
1.100088817841970012523233890533447265625. This doesn't crop up
with single-string JDOQL since the string is embodied directly, so is parsed to
a BigDecimal with that String as input.
Workaround is to change your ifThenElse line to use the following arguments
cand.budget.mul(new BigDecimal("1.2"))
cand.budget.mul(new BigDecimal("1.1"))
hence equivalent BigDecimal literals to the string form. Passes for me if that
change is made.
> 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)
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16675280#comment-16675280 ] Andy Jefferson edited comment on JDO-652 at 11/5/18 6:32 PM: - DataNucleus has supported latest API changes for some time, you're just using the wrong version ... 5.1 is frozen (unless people provide backports), 5.2 is current. Issues with the tests from a cursory scan:- IfElseResult.testPositive2 uses "No Reviewer" instead of "No reviewer". NullResults.testDistinctNavigation is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. NullResults.testNavigation is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. NullResults.testUnique is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. IfElseInFilter.testPositive0 applies an orderBy to JDOQL single-string but not to JDOQLTypedQuery. IfElseInFilter.testPositive1 doesnt set the JDOQLTyped argument (hence the error), and also omits to apply ordering to JDOQLTypedQuery. QueryTest.executeJDOQLTypedQuery incorrectly only makes use of resultClass when deciding to call 'executeResultXXX'. It should also be looking at whether there is a result clause. There are also executeResultXXX methods that don't take in the result class (when that is not specified). No idea what you mean by not being able to use a Map with JDOQLTyped ... you just specify the result class as a Map, like you'd do it as any other result class. Unless you mean just an alias for any result expression? in which case no objection to that, the DN internal code already has that, just not the public api was (Author: andy): DataNucleus has supported latest API changes for some time, you're just using the wrong version ... 5.1 is frozen (unless people provide backports), 5.2 is current. Issues with the tests from a cursory scan:- IfElseResult.testPositive2 uses "No Reviewer" instead of "No reviewer". NullResults.testDistinctNavigation is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. NullResults.testNavigation is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. NullResults.testUnique is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. IfElseInFilter.testPositive0 applies an orderBy to JDOQL single-string but not to JDOQLTypedQuery. IfElseInFilter.testPositive1 doesnt set the JDOQLTyped argument (hence the error), and also omits to apply ordering to JDOQLTypedQuery. No idea what you mean by not being able to use a Map with JDOQLTyped ... you just specify the result class as a Map, like you'd do it as any other result class. Unless you mean just an alias for any result expression? in which case no objection to that, the DN internal code already has that, just not the public api > 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)
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16675280#comment-16675280 ] Andy Jefferson edited comment on JDO-652 at 11/5/18 4:07 PM: - DataNucleus has supported latest API changes for some time, you're just using the wrong version ... 5.1 is frozen (unless people provide backports), 5.2 is current. Issues with the tests from a cursory scan:- IfElseResult.testPositive2 uses "No Reviewer" instead of "No reviewer". NullResults.testDistinctNavigation is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. NullResults.testNavigation is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. NullResults.testUnique is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. IfElseInFilter.testPositive0 applies an orderBy to JDOQL single-string but not to JDOQLTypedQuery. IfElseInFilter.testPositive1 doesnt set the JDOQLTyped argument (hence the error), and also omits to apply ordering to JDOQLTypedQuery. No idea what you mean by not being able to use a Map with JDOQLTyped ... you just specify the result class as a Map, like you'd do it as any other result class. Unless you mean just an alias for any result expression? in which case no objection to that, the DN internal code already has that, just not the public api was (Author: andy): DataNucleus has supported latest API changes for some time, you're just using the wrong version ... 5.1 is frozen (unless people provide backports), 5.2 is current. Issues with the tests from a cursory scan:- IfElseResult.testPositive2 uses "No Reviewer" instead of "No reviewer". NullResults.testDistinctNavigation is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. NullResults.testNavigation is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. NullResults.testUnique is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. IfElseInFilter.testPositive0 applies an orderBy to JDOQL single-string but not to JDOQLTypedQuery. IfElseInFilter.testPositive1 doesnt set the JDOQLTyped argument (hence the error), and also omits to apply ordering to JDOQLTypedQuery. No idea what you mean by not being able to use a Map with JDOQLTyped ... you just specify the result class as a Map, like you'd do it as any other result class. > 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)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16675280#comment-16675280 ] Andy Jefferson commented on JDO-652: DataNucleus has supported latest API changes for some time, you're just using the wrong version ... 5.1 is frozen (unless people provide backports), 5.2 is current. Issues with the tests from a cursory scan:- IfElseResult.testPositive2 uses "No Reviewer" instead of "No reviewer". NullResults.testDistinctNavigation is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. NullResults.testNavigation is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. NullResults.testUnique is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. IfElseInFilter.testPositive0 applies an orderBy to JDOQL single-string but not to JDOQLTypedQuery. IfElseInFilter.testPositive1 doesnt set the JDOQLTyped argument (hence the error), and also omits to apply ordering to JDOQLTypedQuery. No idea what you mean by not being able to use a Map with JDOQLTyped ... you just specify the result class as a Map, like you'd do it as any other result class. > 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)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16651415#comment-16651415 ] Andy Jefferson commented on JDO-652: FYI, DataNucleus also now supports methods on geospatial types. http://www.datanucleus.org:15080/products/accessplatform_5_2/jdo/query.html#jdoql_typed_methods_geospatial though this requires use of the DN-provided "javax.jdo.jar" rather than Apache JDO "jdo-api.jar". Whether support for these types (and the associated query methods) can one day be standardised is left to people to request/discuss. The OGC standardised simple geospatial types a long time ago, as per [http://www.opengeospatial.org/standards/sfa] and DataNucleus has had full support for them since day one. These JDOQLTypedQuery expressions map directly on to the types they define. > 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)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
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)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16613253#comment-16613253
]
Andy Jefferson commented on JDO-652:
I've updated the DN prototype to match Craig's ideas / namings, namely
*JDOQLTypedQuery* gains these methods
{code:java}
/**
* Method to return an "IF (...) ... ELSE ..." expression for use in this query.
* @param type The type returned by the IfElse.
* @return The IfThenElse expression
*/
IfThenElseExpression ifThenElse(Class type);
/**
* Method to return an "IF (...) ... ELSE ..." expression for use in this query.
* @param type The type returned by the IfElse.
* @param ifExpr If expression
* @param ifValue Value to return when the if expression is met
* @param elseValue Value to return when the if expression is not met
* @return The IfThenElse expression
*/
IfThenElseExpression ifThenElse(Class type, BooleanExpression
ifExpr, V ifValue, V elseValue);
/**
* Method to return an "IF (...) ... ELSE ..." expression for use in this query.
* @param type The type returned by the IfElse.
* @param ifExpr If expression
* @param ifValueExpr Expression for value to return when the if expression is
met
* @param elseValueExpr Expression for value to return when the if expression
is not met
* @return The IfThenElse expression
*/
IfThenElseExpression ifThenElse(Class type, BooleanExpression
ifExpr, Expression ifValueExpr, Expression elseValueExpr);
{code}
and there is now *IfThenElseExpression* as follows
{code:java}
public interface IfThenElseExpression extends ComparableExpression
{
/**
* Method to add an "IF (...) ..." clause.
* If called multiple times, will add extra "IF (...) ..." or "ELSE IF (...)
..."
* @param ifExpr The if expression
* @param value The return value
* @return This expression
*/
IfThenElseExpression when(BooleanExpression ifExpr, T value);
/**
* Method to add an "IF (...) ..." clause.
* If called multiple times, will add extra "IF (...) ..." or "ELSE IF (...)
..."
* @param ifExpr The if expression
* @param value The return value expression
* @return This expression
*/
IfThenElseExpression when(BooleanExpression ifExpr, Expression
valueExpr);
/**
* Method to add the "ELSE ..." clause.
* If called multiple times will replace the previous else clause
* @param value The return value
* @return This expression
*/
IfThenElseExpression otherwise(T value);
/**
* Method to add the "ELSE ..." clause.
* If called multiple times will replace the previous else clause
* @param value The return value expression
* @return This expression
*/
IfThenElseExpression otherwise(Expression valueExpr);
}
{code}
The builder methods provided don't cater for the cases where the user wants to
provide a literal for the "if" value and expression for the "else" value (and
vice versa), but i'd put those as minority interest use-cases.
> 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-patch-Andy.txt, JDO-652-patch3.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)
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16610265#comment-16610265
]
Andy Jefferson edited comment on JDO-652 at 9/11/18 8:25 AM:
-
As I hinted at, you specified Double so java generics enforces Double, and Java
generics throws its toys out of the pram. If instead you did
{code:java}
IfElseExpression ifExpr = query.ifElseExpression(Number.class);{code}
then it's fine.
You could look at updating ComparableExpression methods that take in
{code:java}
ComparableExpression{code}
to take in
{code:java}
ComparableExpression{code}
or something similar, to get around Java generics compilation nonsense.
Since (java.lang.)String and (java.util.)Date have no subtypes then their
associated Expression has no need of generics, whereas since (java.lang.)Number
has many subtypes and so its associated Expression does have need of generics.
Further to that we have a need to enforce type precision on some methods down
to the Double/Integer/Float level, such as
{code:java}
NumericExpression avg();{code}
hence it is either have generics on NumericExpression, or have to introduce
DoubleExpression, IntegerExpression, etc, and I don't want to go there.
As for naming, the reason it is called "IfElseExpression" (as opposed to
"IfThenElse") is that all expressions in that package are using the same naming
scheme ... XXXExpression. I've no problem with it being "IfThenElseExpression",
but maybe that is what Craig meant (and not calling it "IfThenElse" without the
Expression)?
was (Author: andy):
As I hinted at, you specified Double so java generics enforces Double, and Java
generics throws its toys out of the pram. If instead you did
{{IfElseExpression ifExpr = query.ifElseExpression(Number.class);}}
then it's fine.
You could look at updating ComparableExpression methods that take in
{code:java}
ComparableExpression{code}
to take in
{code:java}
ComparableExpression{code}
or something similar, to get around Java generics compilation nonsense.
Since (java.lang.)String and (java.util.)Date have no subtypes then their
associated Expression has no need of generics, whereas since (java.lang.)Number
has many subtypes and so its associated Expression does have need of generics.
Further to that we have a need to enforce type precision on some methods down
to the Double/Integer/Float level, such as
{code:java}
NumericExpression avg();{code}
hence it is either have generics on NumericExpression, or have to introduce
DoubleExpression, IntegerExpression, etc, and I don't want to go there.
As for naming, the reason it is called "IfElseExpression" (as opposed to
"IfThenElse") is that all expressions in that package are using the same naming
scheme ... XXXExpression. I've no problem with it being "IfThenElseExpression",
but maybe that is what Craig meant (and not calling it "IfThenElse" without the
Expression)?
> 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-patch-Andy.txt, JDO-652-patch3.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)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16610265#comment-16610265
]
Andy Jefferson commented on JDO-652:
As I hinted at, you specified Double so java generics enforces Double, and Java
generics throws its toys out of the pram. If instead you did
{{IfElseExpression ifExpr = query.ifElseExpression(Number.class);}}
then it's fine.
You could look at updating ComparableExpression methods that take in
{code:java}
ComparableExpression{code}
to take in
{code:java}
ComparableExpression{code}
or something similar, to get around Java generics compilation nonsense.
Since (java.lang.)String and (java.util.)Date have no subtypes then their
associated Expression has no need of generics, whereas since (java.lang.)Number
has many subtypes and so its associated Expression does have need of generics.
Further to that we have a need to enforce type precision on some methods down
to the Double/Integer/Float level, such as
{code:java}
NumericExpression avg();{code}
hence it is either have generics on NumericExpression, or have to introduce
DoubleExpression, IntegerExpression, etc, and I don't want to go there.
As for naming, the reason it is called "IfElseExpression" (as opposed to
"IfThenElse") is that all expressions in that package are using the same naming
scheme ... XXXExpression. I've no problem with it being "IfThenElseExpression",
but maybe that is what Craig meant (and not calling it "IfThenElse" without the
Expression)?
> 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-patch-Andy.txt, JDO-652-patch3.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)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608775#comment-16608775 ] Andy Jefferson commented on JDO-652: And how is the Java API to know about "Number" when you define the type as "Double"? The "IfElseExpression" represents the type that it returns. You passed "Double" to the builder method, not "Number". Why would the builder method take 3 arguments? An "If-Else" can have multiple "if"s and one "else". Specifying the "if-then" clauses individually makes it more fluent IMHO. I can't see how "IfThenElse" can extend DoubleExpression ... because the type is "IfThenElse" ... i.e dependent on the type that it returns. And if the "If-Else" is returning a String? or a Date? IfElseNumeric, IfElseString and so on? (which makes it way less extensible). Why not provide some code that demonstrates how that will work (and preferably an implementation, to go in [https://github.com/datanucleus/datanucleus-api-jdo/blob/master/src/main/java/org/datanucleus/api/jdo/query/IfElseExpressionImpl.java] ) > 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-patch-Andy.txt, JDO-652-patch3.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)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16605781#comment-16605781
]
Andy Jefferson commented on JDO-652:
See
[https://github.com/datanucleus/javax.jdo/commit/34129e8c995db533545a1e882823edffd0a4c204]
for a prototype of If-Else handling. This means that you can write such as
the following
{{ JDOQLTypedQuery tq = pm.newJDOQLTypedQuery(Person.class);}}
{{ QPerson cand = QPerson.jdoCandidate;}}
{{ IfElseExpression ageGroupExpr =
tq.ifElseExpression(String.class);}}
{{ ageGroupExpr.ifThen(cand.age.lt(21), "Student");}}
{{ ageGroupExpr.ifThen(cand.age.ge(21).and(cand.age.lt(65)), "Worker");}}
{{ ageGroupExpr.elseEnd("Retired");}}
{{ tq.result(false, ageGroupExpr);}}
> 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-patch-Andy.txt, JDO-652-patch3.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)
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16601154#comment-16601154
]
Andy Jefferson edited comment on JDO-652 at 9/2/18 12:52 PM:
-
Re: mail to jdo-dev mailing list (which I don't subscribe to, and besides this
is the issue in JIRA so ought to be the focal point for any dev discussion
specific to this API),
*IF-THEN-ELSE* : this was added to JDOQL after the JDOQLTypedQuery API was
designed. Consequently there is no handling for it. What QueryDSL does is
likely the best option to use as a guide for how to provide it (see
[http://www.querydsl.com/static/querydsl/4.1.3/reference/html_single/#d0e2105]
and
[http://www.querydsl.com/static/querydsl/4.1.4/apidocs/com/querydsl/core/types/dsl/CaseBuilder.html]
). Adapting it to JDO we could have something like this. Create a
CaseExpression via builder method on JDOQLTypedQuery
CaseExpression caseExpr = JDOQLTypedQuery.newCaseExpression();
and then have methods on CaseExpression to
CaseExpression when(BooleanExpression condition, Expression valueExpr);
CaseExpression else(Expression valueExpr);
Or go via the QueryDSL CaseBuilder idea? If you have a better idea, propose
something?
*Ordering NULLS FIRST/LAST* : again, not part of JDOQL when this API was
designed. So we could do something like this
OrderExpression
public enum OrderNullsPosition
{ FIRST, LAST }
/**
* Accessor for the position of nulls with this expression.
* @return The nulls position (or null if not defined)
*/
OrderNullsPosition getNullsPosition();
/**
* Method to set nulls to be ordered BEFORE non-nulls.
* @return The order expression
*/
OrderExpression nullsFirst();
/**
* Method to set nulls to be ordered AFTER non-nulls.
* @return The order expression
*/
OrderExpression nullsLast();
If you have a better idea, propose something?
*Map.get(Expression)* : Was only added to JDOQL later in the dev cycle, so
just add it?
*sqrt(), abs() etc for primitive wrappers* : A primitive wrapper is a
NumericExpression, so are already part of the API. You likely need
_datanucleus-jdo-query v5.0.6_ to see them, but that is not an error in the
API, just the implementation having them later.
*StringExpression.startsWith(String, int)* : Was only added to JDOQL later in
the dev cycle, so just add it. And while at it add the equivalent(s) taking in
StringExpression, and NumericExpression.
was (Author: andy):
Re: mail to jdo-dev mailing list (which I don't subscribe to, and besides this
is the issue in JIRA so ought to be the focal point for any dev discussion
specific to this API),
*IF-THEN-ELSE* : this was added to JDOQL after the JDOQLTypedQuery API was
designed. Consequently there is no handling for it. What QueryDSL does is
likely the best option to use as a guide for how to provide it (see
[http://www.querydsl.com/static/querydsl/4.1.3/reference/html_single/#d0e2105]
and
[http://www.querydsl.com/static/querydsl/4.1.4/apidocs/com/querydsl/core/types/dsl/CaseBuilder.html]
). Adapting it to JDO we could have something like this. Create a
CaseExpression via builder method on JDOQLTypedQuery
CaseExpression caseExpr = JDOQLTypedQuery.newCaseExpression();
and then have methods on CaseExpression to
CaseExpression when(BooleanExpression condition, Expression valueExpr);
CaseExpression else(Expression valueExpr);
Or go via the QueryDSL CaseBuilder idea? If you have a better idea, propose
something?
*Ordering NULLS FIRST/LAST* : again, not part of JDOQL when this API was
designed. So we could do something like this
ComparableExpression
/**
* Method to set nulls to be ordered BEFORE non-nulls.
* @return The order expression
*/
OrderExpression nullsFirst();
/**
* Method to set nulls to be ordered AFTER non-nulls.
* @return The order expression
*/
OrderExpression nullsLast();
OrderExpression
public enum OrderNullsPosition
{
FIRST,
LAST
}
/**
* Accessor for the position of nulls with this expression.
* @return The nulls position (or null if not defined)
*/
OrderNullsPosition getNullsPosition();
If you have a better idea, propose something?
*Map.get(Expression)* : Was only added to JDOQL later in the dev cycle, so
just add it?
*sqrt(), abs() etc for primitive wrappers* : A primitive wrapper is a
NumericExpression, so are already part of the API. You likely need
_datanucleus-jdo-query v5.0.6_ to see them, but that is not an error in the
API, just the implementation having them later.
*StringExpression.startsWith(String, int)* : Was only added to JDOQL later in
the dev cycle, so just add it. And while at it add the equivalent(s) taking in
StringExpression, and
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16601154#comment-16601154
]
Andy Jefferson commented on JDO-652:
Re: mail to jdo-dev mailing list (which I don't subscribe to, and besides this
is the issue in JIRA so ought to be the focal point for any dev discussion
specific to this API),
*IF-THEN-ELSE* : this was added to JDOQL after the JDOQLTypedQuery API was
designed. Consequently there is no handling for it. What QueryDSL does is
likely the best option to use as a guide for how to provide it (see
[http://www.querydsl.com/static/querydsl/4.1.3/reference/html_single/#d0e2105]
and
[http://www.querydsl.com/static/querydsl/4.1.4/apidocs/com/querydsl/core/types/dsl/CaseBuilder.html]
). Adapting it to JDO we could have something like this. Create a
CaseExpression via builder method on JDOQLTypedQuery
CaseExpression caseExpr = JDOQLTypedQuery.newCaseExpression();
and then have methods on CaseExpression to
CaseExpression when(BooleanExpression condition, Expression valueExpr);
CaseExpression else(Expression valueExpr);
Or go via the QueryDSL CaseBuilder idea? If you have a better idea, propose
something?
*Ordering NULLS FIRST/LAST* : again, not part of JDOQL when this API was
designed. So we could do something like this
ComparableExpression
/**
* Method to set nulls to be ordered BEFORE non-nulls.
* @return The order expression
*/
OrderExpression nullsFirst();
/**
* Method to set nulls to be ordered AFTER non-nulls.
* @return The order expression
*/
OrderExpression nullsLast();
OrderExpression
public enum OrderNullsPosition
{
FIRST,
LAST
}
/**
* Accessor for the position of nulls with this expression.
* @return The nulls position (or null if not defined)
*/
OrderNullsPosition getNullsPosition();
If you have a better idea, propose something?
*Map.get(Expression)* : Was only added to JDOQL later in the dev cycle, so
just add it?
*sqrt(), abs() etc for primitive wrappers* : A primitive wrapper is a
NumericExpression, so are already part of the API. You likely need
_datanucleus-jdo-query v5.0.6_ to see them, but that is not an error in the
API, just the implementation having them later.
*StringExpression.startsWith(String, int)* : Was only added to JDOQL later in
the dev cycle, so just add it. And while at it add the equivalent(s) taking in
StringExpression, and NumericExpression.
> 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-patch-Andy.txt, JDO-652-patch3.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)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559995#comment-16559995 ] Andy Jefferson commented on JDO-652: In case you were expecting some DataNucleus version that uses/implements those methods, all DN nightly builds have had those methods for some time. > 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-patch-Andy.txt, JDO-652-patch2.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)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16548828#comment-16548828 ] Andy Jefferson commented on JDO-652: About StringExpression.add(String); yes, add it. I've only added what I've come across that I've needed. All other methods have both options. > 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-patch-Andy.txt, JDO-652-patch.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)
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547654#comment-16547654 ] Andy Jefferson edited comment on JDO-652 at 7/18/18 10:18 AM: -- Tried to apply some updates but cannot access "svn.apache.org" (via command line, or browser), svn: E170013: Unable to connect to a repository at URL '[http://svn.apache.org/repos/asf/db/jdo'] svn: E120108: Error running context: The server unexpectedly closed the connection. I can use svn to other sites, I can use Git to other sites. So presumably someone at Apache knows what those error codes mean; nothing in my logs. Blocked my IP ? Tried to upload a patch here (Firefox, also tried Chrome) and JIRA says "JIRA could not attach the file as there was a missing token. Please try attaching the file again." WTF? Glad we dumped JIRA from the DataNucleus project. I attach the proposed updates to the api project here in text form, since have no other way. The aim of this is to sort out some of the generics specifications of (some of) the JDOQLTyped expressions. Thx Index: src/main/java/javax/jdo/query/ComparableExpression.java === — src/main/java/javax/jdo/query/ComparableExpression.java (revision 1834479) +++ src/main/java/javax/jdo/query/ComparableExpression.java (working copy) @@ -28,7 +28,7 @@ * @param expr Other expression * @return Whether this is less than the other */ - BooleanExpression lt(ComparableExpression expr); + BooleanExpression lt(ComparableExpression expr); /** * Method returning whether this expression is less than the literal. @@ -42,7 +42,7 @@ * @param expr Other expression * @return Whether this is less than or equal the other */ - BooleanExpression lteq(ComparableExpression expr); + BooleanExpression lteq(ComparableExpression expr); /** * Method returning whether this expression is less than or equal the literal. @@ -56,7 +56,7 @@ * @param expr Other expression * @return Whether this is greater than the other */ - BooleanExpression gt(ComparableExpression expr); + BooleanExpression gt(ComparableExpression expr); /** * Method returning whether this expression is greater than the literal. @@ -70,7 +70,7 @@ * @param expr Other expression * @return Whether this is greater than or equal to the other */ - BooleanExpression gteq(ComparableExpression expr); + BooleanExpression gteq(ComparableExpression expr); /** * Method returning whether this expression is greater than or equal the literal. @@ -83,23 +83,23 @@ * Method to return a numeric expression representing the aggregated minimum of this expression. * @return Numeric expression for the minimum */ - NumericExpression min(); + NumericExpression min(); /** * Method to return a numeric expression representing the aggregated maximum of this expression. * @return Numeric expression for the maximum */ - NumericExpression max(); + NumericExpression max(); /** * Method to return an order expression for this expression in ascending order. * @return The order expression */ - OrderExpression asc(); + OrderExpression asc(); /** * Method to return an order expression for this expression in descending order. * @return The order expression */ - OrderExpression desc(); -} \ No newline at end of file + OrderExpression desc(); +} Index: src/main/java/javax/jdo/query/NumericExpression.java === — src/main/java/javax/jdo/query/NumericExpression.java (revision 1834479) +++ src/main/java/javax/jdo/query/NumericExpression.java (working copy) @@ -109,7 +109,7 @@ * Method to return a numeric expression representing the aggregated average of this expression. * @return Numeric expression for the average */ - NumericExpression avg(); + NumericExpression avg(); /** * Method to return a numeric expression representing the aggregated sum of this expression. @@ -209,4 +209,4 @@ * @return Bitwise XOR expression */ NumericExpression bXor(NumericExpression bitExpr); -} \ No newline at end of file +} was (Author: andy): Tried to upload a patch since cannot access "svn.apache.org" (via command line, or browser), svn: E170013: Unable to connect to a repository at URL '[http://svn.apache.org/repos/asf/db/jdo'] svn: E120108: Error running context: The server unexpectedly closed the connection. I can use svn to other sites, I can use Git to other sites. So presumably someone at Apache knows what those error codes mean; nothing in my logs. Blocked my IP ? Tried to upload a patch here (Firefox, also tried Chrome) and JIRA says "JIRA could not attach the file as there was a missing token. Please try attaching the file again." WTF? Glad we dumped JIRA from the DataNucleus project. I attach the proposed updates to the api project here in
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547654#comment-16547654 ] Andy Jefferson commented on JDO-652: Tried to upload a patch since cannot access "svn.apache.org" (via command line, or browser), svn: E170013: Unable to connect to a repository at URL '[http://svn.apache.org/repos/asf/db/jdo'] svn: E120108: Error running context: The server unexpectedly closed the connection. I can use svn to other sites, I can use Git to other sites. So presumably someone at Apache knows what those error codes mean; nothing in my logs. Blocked my IP ? Tried to upload a patch here (Firefox, also tried Chrome) and JIRA says "JIRA could not attach the file as there was a missing token. Please try attaching the file again." WTF? Glad we dumped JIRA from the DataNucleus project. I attach the proposed updates to the api project here in text form, since have no other way. The aim of this is to sort out some of the generics specifications of (some of) the JDOQLTyped expressions. Thx Index: src/main/java/javax/jdo/query/ComparableExpression.java === --- src/main/java/javax/jdo/query/ComparableExpression.java (revision 1834479) +++ src/main/java/javax/jdo/query/ComparableExpression.java (working copy) @@ -28,7 +28,7 @@ * @param expr Other expression * @return Whether this is less than the other */ - BooleanExpression lt(ComparableExpression expr); + BooleanExpression lt(ComparableExpression expr); /** * Method returning whether this expression is less than the literal. @@ -42,7 +42,7 @@ * @param expr Other expression * @return Whether this is less than or equal the other */ - BooleanExpression lteq(ComparableExpression expr); + BooleanExpression lteq(ComparableExpression expr); /** * Method returning whether this expression is less than or equal the literal. @@ -56,7 +56,7 @@ * @param expr Other expression * @return Whether this is greater than the other */ - BooleanExpression gt(ComparableExpression expr); + BooleanExpression gt(ComparableExpression expr); /** * Method returning whether this expression is greater than the literal. @@ -70,7 +70,7 @@ * @param expr Other expression * @return Whether this is greater than or equal to the other */ - BooleanExpression gteq(ComparableExpression expr); + BooleanExpression gteq(ComparableExpression expr); /** * Method returning whether this expression is greater than or equal the literal. @@ -83,23 +83,23 @@ * Method to return a numeric expression representing the aggregated minimum of this expression. * @return Numeric expression for the minimum */ - NumericExpression min(); + NumericExpression min(); /** * Method to return a numeric expression representing the aggregated maximum of this expression. * @return Numeric expression for the maximum */ - NumericExpression max(); + NumericExpression max(); /** * Method to return an order expression for this expression in ascending order. * @return The order expression */ - OrderExpression asc(); + OrderExpression asc(); /** * Method to return an order expression for this expression in descending order. * @return The order expression */ - OrderExpression desc(); -} \ No newline at end of file + OrderExpression desc(); +} Index: src/main/java/javax/jdo/query/NumericExpression.java === --- src/main/java/javax/jdo/query/NumericExpression.java (revision 1834479) +++ src/main/java/javax/jdo/query/NumericExpression.java (working copy) @@ -109,7 +109,7 @@ * Method to return a numeric expression representing the aggregated average of this expression. * @return Numeric expression for the average */ - NumericExpression avg(); + NumericExpression avg(); /** * Method to return a numeric expression representing the aggregated sum of this expression. @@ -209,4 +209,4 @@ * @return Bitwise XOR expression */ NumericExpression bXor(NumericExpression bitExpr); -} \ No newline at end of file +} > 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-patch.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
[jira] [Commented] (JDO-770) Switch from svn to git
[
https://issues.apache.org/jira/browse/JDO-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16544892#comment-16544892
]
Andy Jefferson commented on JDO-770:
The sooner this can be done the better for all. I just tried to get current
code using (from the website)
{{svn checkout [http://svn.apache.org/repos/asf/db/jdo]}}
and was met with
{{svn: E170013: Unable to connect to a repository at URL
'http://svn.apache.org/repos/asf/db/jdo'}}
{{svn: E120108: Error running context: The server unexpectedly closed the
connection.}}
Nice, so much for that idea.
> Switch from svn to git
> --
>
> Key: JDO-770
> URL: https://issues.apache.org/jira/browse/JDO-770
> Project: JDO
> Issue Type: Improvement
> Components: site and infrastructure
>Affects Versions: JDO 3.1
>Reporter: Michael Bouschen
>Assignee: Craig L Russell
>Priority: Major
> Fix For: JDO 3.2
>
>
> We should consider switching from svn to git. The reason to make jdo
> available via git is to remove a possible barrier to new contributors.
> There are several alternatives if we decide to offer git as an alternative to
> svn:
> * migrating all the code to git
> * creating a read-only git mirror
> * creating a read-write bridge.
> See [Git at Apache | https://git.apache.org/] for more details.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16542799#comment-16542799 ] Andy Jefferson commented on JDO-652: FYI JDOQL "JDOHelper.getObjectId()" is PersistableExpression.jdoObjectId() JDOQL "JDOHelper.getVersion()" is PersistableExpression.jdoVersion() since they pertain to the object that we are requiring the "id" and "version" for. > 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-patch.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)
[jira] [Commented] (JDO-774) Restructure JDO maven project
[ https://issues.apache.org/jira/browse/JDO-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16499850#comment-16499850 ] Andy Jefferson commented on JDO-774: In case its of any use, DataNucleus manages a (semi-)mirrored API project to allow us to do releases, and it uses the standard Maven layout (pretty much the same as you're proposing). It is at https://github.com/datanucleus/javax.jdo > Restructure JDO maven project > - > > Key: JDO-774 > URL: https://issues.apache.org/jira/browse/JDO-774 > Project: JDO > Issue Type: Improvement > Components: api, tck >Affects Versions: JDO 3.1 >Reporter: Michael Bouschen >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.2 > > > We should consider changing the structure of the project to match the > standard (default) maven structure: trunk/main/src/java and > trunk/test/src/java > See > [https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html] > for the maven standard directory layout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JDO-771) Update requirement of ConnectionDriverName since JDBC 4 changed requirements
[ https://issues.apache.org/jira/browse/JDO-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316400#comment-16316400 ] Andy Jefferson commented on JDO-771: The only other thing I'd add is that when using JDO for non-RDBMS datastores, providers may have made use of the driverName to specify a driver. Since that is not covered by JDBC then may still be usable. Perhaps update the spec that its no longer required for RDBMS usage? > Update requirement of ConnectionDriverName since JDBC 4 changed requirements > > > Key: JDO-771 > URL: https://issues.apache.org/jira/browse/JDO-771 > Project: JDO > Issue Type: Improvement > Components: specification, tck >Reporter: Andy Jefferson >Priority: Minor > > JDBC 4.0 changed the requirement for specifying a JDBC driver name. > Previously an application had to load the class to register the driver by use > of Class.forName. > All JDBC 4.0+ drivers should register themselves. See > https://community.oracle.com/docs/DOC-983612 > This likely means that a JDO provider will not require the > javax.jdo.option.ConnectionDriverName to be supplied. > DataNucleus (v5.1.5+) certainly doesn't require it, and only previously used > it for loading the driver as per previous JDBC semantics. > This is only referred to in section 11.1 and Appendix G of the spec that I > can see. Perhaps we can omit it in JDO 3.2+, particularly as the JRE in use > will require JDBC v4+? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JDO-771) Update requirement of ConnectionDriverName since JDBC 4 changed requirements
[ https://issues.apache.org/jira/browse/JDO-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16304461#comment-16304461 ] Andy Jefferson commented on JDO-771: The aforementioned system property is not set by 99.9% of "applications", and the service loader is where the drivers should be found from. That (property) would (only) be useful to explicitly define which precise one when multiple exist for the specified connection URL, and I've never come across such a situation, ever. Either way, DataNucleus has never ever used the connectionDriverName for anything more than JDBC "Class.forName", which is now redundant in this context, so this issue is simply pointing out that the property is redundant for all current DataNucleus (and JDO?) usage. > Update requirement of ConnectionDriverName since JDBC 4 changed requirements > > > Key: JDO-771 > URL: https://issues.apache.org/jira/browse/JDO-771 > Project: JDO > Issue Type: Improvement > Components: specification, tck >Reporter: Andy Jefferson >Priority: Minor > > JDBC 4.0 changed the requirement for specifying a JDBC driver name. > Previously an application had to load the class to register the driver by use > of Class.forName. > All JDBC 4.0+ drivers should register themselves. See > https://community.oracle.com/docs/DOC-983612 > This likely means that a JDO provider will not require the > javax.jdo.option.ConnectionDriverName to be supplied. > DataNucleus (v5.1.5+) certainly doesn't require it, and only previously used > it for loading the driver as per previous JDBC semantics. > This is only referred to in section 11.1 and Appendix G of the spec that I > can see. Perhaps we can omit it in JDO 3.2+, particularly as the JRE in use > will require JDBC v4+? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (JDO-771) Update requirement of ConnectionDriverName since JDBC 4 changed requirements
Andy Jefferson created JDO-771: -- Summary: Update requirement of ConnectionDriverName since JDBC 4 changed requirements Key: JDO-771 URL: https://issues.apache.org/jira/browse/JDO-771 Project: JDO Issue Type: Improvement Components: specification, tck Reporter: Andy Jefferson Priority: Minor JDBC 4.0 changed the requirement for specifying a JDBC driver name. Previously an application had to load the class to register the driver by use of Class.forName. All JDBC 4.0+ drivers should register themselves. See https://community.oracle.com/docs/DOC-983612 This likely means that a JDO provider will not require the javax.jdo.option.ConnectionDriverName to be supplied. DataNucleus (v5.1.5+) certainly doesn't require it, and only previously used it for loading the driver as per previous JDBC semantics. This is only referred to in section 11.1 and Appendix G of the spec that I can see. Perhaps we can omit it in JDO 3.2+, particularly as the JRE in use will require JDBC v4+? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JDO-767) JDO TCK lifecycle tests fail
[ https://issues.apache.org/jira/browse/JDO-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16274126#comment-16274126 ] Andy Jefferson commented on JDO-767: Simple viewing of https://svn.apache.org/viewvc/db/jdo/trunk/tck/src/conf/jdori-pmf.properties?view=markup reveals that it has a DN property applicable up to and including DN 5.0, but not for DN 5.1, namely datanucleus.nontx.atomic=false but then you likely would get a message in the log about that property being not known with DN 5.1 Using datanucleus.transaction.nontx.atomic=false is what I use, and that is consistent with DN migration notes for moving to v5.1 http://www.datanucleus.org:15080/products/accessplatform_5_1/migration.html#_migration_from_5_0_6_to_5_1_0_m1 > JDO TCK lifecycle tests fail > > > Key: JDO-767 > URL: https://issues.apache.org/jira/browse/JDO-767 > Project: JDO > Issue Type: Bug > Components: tck >Affects Versions: JDO 3.1 >Reporter: Craig L Russell >Assignee: Tilmann Zäschke > Fix For: JDO 3.2 > > > cat dsid-lifecycle-tck.txt > 10:14:11,507 (main) INFO [org.apache.jdo.tck] - Exception during setUp or > runtest: > junit.framework.AssertionFailedError: > Assertion A5.6.2-6 (NontransactionalWriteDatastoreRollback) failed: after > datastore rollback > expected: 100 > actual: 999 > at junit.framework.Assert.fail(Assert.java:47) > at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1245) > at > org.apache.jdo.tck.lifecycle.NontransactionalWriteDatastoreRollback.testDatastoreRollback(NontransactionalWriteDatastoreRollback.java:87) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at junit.framework.TestCase.runTest(TestCase.java:154) > at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:284) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.textui.TestRunner.doRun(TestRunner.java:116) > at > org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108) > at > org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148) > at > org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123) > 10:14:11,527 (main) INFO [org.apache.jdo.tck] - Exception during setUp or > runtest: > junit.framework.AssertionFailedError: > Assertion A5.6.2-4 (NontransactionalWriteDatastoreCommitConflict) failed: > after datastore commit with conflict > expected: 999 > actual: 555 > at junit.framework.Assert.fail(Assert.java:47) > at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1245) > at > org.apache.jdo.tck.lifecycle.NontransactionalWriteDatastoreCommitConflict.testDatastoreCommitConflict(NontransactionalWriteDatastoreCommitConflict.java:90) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at junit.framework.TestCase.runTest(TestCase.java:154) > at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:284) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.textui.TestRunner.doRun(TestRunner.java:116) > at > org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108) > at > org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148) > at > org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123) > 10:14:11,532 (main) INFO [org.apache.jdo.tck] - Exception during setUp or
[jira] [Commented] (JDO-767) JDO TCK lifecycle tests fail
[ https://issues.apache.org/jira/browse/JDO-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16272251#comment-16272251 ] Andy Jefferson commented on JDO-767: Linux 64-bit (kernel 4.9.56), OpenJDK JVM (1.8.0.141), with 8Gb RAM. Differences can also highlight with garbage collection and L1/L2 caching, hence why I mention the RAM. > JDO TCK lifecycle tests fail > > > Key: JDO-767 > URL: https://issues.apache.org/jira/browse/JDO-767 > Project: JDO > Issue Type: Bug > Components: tck >Affects Versions: JDO 3.1 >Reporter: Craig L Russell >Assignee: Tilmann Zäschke > Fix For: JDO 3.2 > > > cat dsid-lifecycle-tck.txt > 10:14:11,507 (main) INFO [org.apache.jdo.tck] - Exception during setUp or > runtest: > junit.framework.AssertionFailedError: > Assertion A5.6.2-6 (NontransactionalWriteDatastoreRollback) failed: after > datastore rollback > expected: 100 > actual: 999 > at junit.framework.Assert.fail(Assert.java:47) > at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1245) > at > org.apache.jdo.tck.lifecycle.NontransactionalWriteDatastoreRollback.testDatastoreRollback(NontransactionalWriteDatastoreRollback.java:87) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at junit.framework.TestCase.runTest(TestCase.java:154) > at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:284) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.textui.TestRunner.doRun(TestRunner.java:116) > at > org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108) > at > org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148) > at > org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123) > 10:14:11,527 (main) INFO [org.apache.jdo.tck] - Exception during setUp or > runtest: > junit.framework.AssertionFailedError: > Assertion A5.6.2-4 (NontransactionalWriteDatastoreCommitConflict) failed: > after datastore commit with conflict > expected: 999 > actual: 555 > at junit.framework.Assert.fail(Assert.java:47) > at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1245) > at > org.apache.jdo.tck.lifecycle.NontransactionalWriteDatastoreCommitConflict.testDatastoreCommitConflict(NontransactionalWriteDatastoreCommitConflict.java:90) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at junit.framework.TestCase.runTest(TestCase.java:154) > at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:284) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.textui.TestRunner.doRun(TestRunner.java:116) > at > org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108) > at > org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148) > at > org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123) > 10:14:11,532 (main) INFO [org.apache.jdo.tck] - Exception during setUp or > runtest: > junit.framework.AssertionFailedError: > Assertion A5.6.2-10 (NontransactionalWriteOptimisticRollback) failed: after > optimistic rollback > expected: 100 > actual: 999 > at junit.framework.Assert.fail(Assert.java:47) > at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1245) > at >
[jira] [Commented] (JDO-767) JDO TCK lifecycle tests fail
[ https://issues.apache.org/jira/browse/JDO-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16262323#comment-16262323 ] Andy Jefferson commented on JDO-767: JDO TCK (SVN trunk) passes for me, and always has from the point where DN passed it for the first time; I don't release code that breaks tests (ever). If someone gets some failure then they see something I don't see, so they need to investigate it. PS DN "lifecycle state transition" code has not changed in years either. > JDO TCK lifecycle tests fail > > > Key: JDO-767 > URL: https://issues.apache.org/jira/browse/JDO-767 > Project: JDO > Issue Type: Bug > Components: tck >Affects Versions: JDO 3.1 >Reporter: Craig L Russell >Assignee: Tilmann Zäschke > Fix For: JDO 3.2 > > > cat dsid-lifecycle-tck.txt > 10:14:11,507 (main) INFO [org.apache.jdo.tck] - Exception during setUp or > runtest: > junit.framework.AssertionFailedError: > Assertion A5.6.2-6 (NontransactionalWriteDatastoreRollback) failed: after > datastore rollback > expected: 100 > actual: 999 > at junit.framework.Assert.fail(Assert.java:47) > at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1245) > at > org.apache.jdo.tck.lifecycle.NontransactionalWriteDatastoreRollback.testDatastoreRollback(NontransactionalWriteDatastoreRollback.java:87) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at junit.framework.TestCase.runTest(TestCase.java:154) > at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:284) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.textui.TestRunner.doRun(TestRunner.java:116) > at > org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108) > at > org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148) > at > org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123) > 10:14:11,527 (main) INFO [org.apache.jdo.tck] - Exception during setUp or > runtest: > junit.framework.AssertionFailedError: > Assertion A5.6.2-4 (NontransactionalWriteDatastoreCommitConflict) failed: > after datastore commit with conflict > expected: 999 > actual: 555 > at junit.framework.Assert.fail(Assert.java:47) > at org.apache.jdo.tck.JDO_Test.failOnError(JDO_Test.java:1245) > at > org.apache.jdo.tck.lifecycle.NontransactionalWriteDatastoreCommitConflict.testDatastoreCommitConflict(NontransactionalWriteDatastoreCommitConflict.java:90) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at junit.framework.TestCase.runTest(TestCase.java:154) > at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:284) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.textui.TestRunner.doRun(TestRunner.java:116) > at > org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108) > at > org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148) > at > org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123) > 10:14:11,532 (main) INFO [org.apache.jdo.tck] - Exception during setUp or > runtest: > junit.framework.AssertionFailedError: > Assertion A5.6.2-10 (NontransactionalWriteOptimisticRollback) failed: after > optimistic rollback > expected: 100 > actual: 999 > at junit.framework.Assert.fail(Assert.java:47) > at
[jira] [Commented] (JDO-745) Support bitwise operations in JDOQL
[ https://issues.apache.org/jira/browse/JDO-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16187457#comment-16187457 ] Andy Jefferson commented on JDO-745: Does Apache Derby now support some bitwise operators? because it certainly never used to (hence DataNucleus not supporting it). If it still does not then is the test of value when the TCK only runs with Derby? See https://stackoverflow.com/questions/11101333/bitwise-operator-in-apache-derby Regarding having the TCK runnable on other RDBMS, I'd welcome that, but the significant blocker on that is that the "exectck" was written explicitly to use this Derby "ijs" seemingly, rather than using JDBC, like the code in https://github.com/datanucleus/datanucleus-rdbms/blob/master/src/main/java/org/datanucleus/store/rdbms/RDBMSStoreManager.java#L4349 > Support bitwise operations in JDOQL > --- > > Key: JDO-745 > URL: https://issues.apache.org/jira/browse/JDO-745 > Project: JDO > Issue Type: New Feature > Components: specification, tck >Reporter: Andy Jefferson >Assignee: Michael Bouschen > Fix For: JDO 3.2 > > Attachments: JDO-745.patch, JDO-745-patch2.txt > > > The tests BooleanLogicalAND.testNegative, BooleanLogicalOR.testNegative don't > test use of a boolean logical AND/OR. They actually test for an integer being > used with the "&" and "|" operators. Sadly this means that any implementation > that attempts to provide a vendor extension of support for bitwise AND/OR > (for those RDBMS that support it) cannot pass the TCK. > Perhaps add an "optional feature" for the vendor to support bitwise > operations, and then don't run that test if so. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JDO-764) Allow JDO annotations to be used in meta-annotations
[
https://issues.apache.org/jira/browse/JDO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16108464#comment-16108464
]
Andy Jefferson commented on JDO-764:
Firstly, the only reason you can get duplicated annotations is through use of
meta-annotations, and likely the Java compiler people never bothered adding a
check for that because they never thought of it ... because they have a check
for normal annotation usage, preventing multiple @PersistenceCapable (to
protect people from themselves).
Secondly, an annotation has to have a value defined for every attribute.
Consequently
@PersistenceCapable(table="MY_TABLE")
@PersistenceCapable(detachable="true", identityType=IdentityType.DATASTORE)
means
@javax.jdo.annotations.PersistenceCapable(schema=, extensions=[],
objectIdClass=void, identityType=UNSPECIFIED, catalog=, detachable=,
members=[], requiresExtent=, cacheable=true, embeddedOnly=, table=MY_TABLE,
serializeRead=false)
@javax.jdo.annotations.PersistenceCapable(schema=, extensions=[],
objectIdClass=void, identityType=DATASTORE, catalog=, detachable=true,
members=[], requiresExtent=, cacheable=true, embeddedOnly=, table=,
serializeRead=false)
and that means that there is no way of knowing if a user has specified
something as some value (which may or may not be the same as the default) or it
took the default. The only way you can process those as a result is to read in
the first then read in the second. I see no plausible "merge" process ... which
is presumably why people are prevented from doing this with normal annotations.
But if you have some magic code to know what is specified by the user, then
feel free to propose a pull request for DataNucleus. No, I don't like
"unpredictable" results.
My use-case for requesting this feature is from people specifying annotations
on real applications, wanting to reduce the amount of boiler plate code;
merging does not come into their use-case.
> Allow JDO annotations to be used in meta-annotations
>
>
> Key: JDO-764
> URL: https://issues.apache.org/jira/browse/JDO-764
> Project: JDO
> Issue Type: Improvement
> Components: api, specification
>Affects Versions: JDO 3.1
>Reporter: Andy Jefferson
> Fix For: JDO 3.2
>
> Attachments: jdo-764.patch
>
>
> By default annotations are used directly in a persistable class. Java
> additionally allows annotations to be formed of other annotations. This is
> particularly useful where a user has a particular combination of annotations
> to set on a class/field/method and wants to simply annotate with an
> abbreviated form. For example, specifying attributes of an annotation
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> or formed of multiple annotations
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> These can be represented as meta-annotations like this
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> public @interface DatastoreIdPersistable
> {
> }
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> public @interface MultitenantPersistable
> {
> }
> and the user can subsequently just annotate their persistable class as
> @DatastoreIdPersistable
> public class MyClass1 {...}
> @MultitenantPersistable
> public class MyClass2 {...}
> The work required to support this in the JDO spec is simply to update the
> following annotations to add @Target({ElementType.ANNOTATION_TYPE})
> The annotations requiring this are
> @Element, @EmbeddedId, @Key, @NotPersistent, @Order, @Persistent,
> @Serialized, @Transactional, and @Value (all other annotations already have
> @Target({ElementType.TYPE}) which already permits their usage in
> meta-annotations.
> The same is proposed for JPA 2.2, see
> https://github.com/javaee/jpa-spec/issues/43
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JDO-764) Allow JDO annotations to be used in meta-annotations
[
https://issues.apache.org/jira/browse/JDO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16103024#comment-16103024
]
Andy Jefferson commented on JDO-764:
Why does the patch result in things like this
@PersistenceCapable(table="...")
@PersistenceCapable(detachable="true", identityType=IdentityType.DATASTORE)
@DatastoreIdentity(strategy=IdGeneratorStrategy.IDENTITY,
column="DATASTORE_IDENTITY")
@Discriminator(strategy=DiscriminatorStrategy.CLASS_NAME,
column="DISCRIMINATOR", indexed="true")
@Inheritance(strategy=InheritanceStrategy.NEW_TABLE)
public class XXX {...}
You have duplicated @PersistenceCapable, so which will be used ? likely the
first that is presented to the accessing code by Java.
No "merging" will take place in DataNucleus code, because it should never
expect such things. The proposal to support "meta-annotations" was not a
proposal to support merging of duplicated annotations (with normal annotation
usage you will never get duplications, so there is no basic requirement to
support merging there)
> Allow JDO annotations to be used in meta-annotations
>
>
> Key: JDO-764
> URL: https://issues.apache.org/jira/browse/JDO-764
> Project: JDO
> Issue Type: Improvement
> Components: api, specification
>Affects Versions: JDO 3.1
>Reporter: Andy Jefferson
> Fix For: JDO 3.2
>
> Attachments: jdo-764.patch
>
>
> By default annotations are used directly in a persistable class. Java
> additionally allows annotations to be formed of other annotations. This is
> particularly useful where a user has a particular combination of annotations
> to set on a class/field/method and wants to simply annotate with an
> abbreviated form. For example, specifying attributes of an annotation
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> or formed of multiple annotations
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> These can be represented as meta-annotations like this
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> public @interface DatastoreIdPersistable
> {
> }
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> public @interface MultitenantPersistable
> {
> }
> and the user can subsequently just annotate their persistable class as
> @DatastoreIdPersistable
> public class MyClass1 {...}
> @MultitenantPersistable
> public class MyClass2 {...}
> The work required to support this in the JDO spec is simply to update the
> following annotations to add @Target({ElementType.ANNOTATION_TYPE})
> The annotations requiring this are
> @Element, @EmbeddedId, @Key, @NotPersistent, @Order, @Persistent,
> @Serialized, @Transactional, and @Value (all other annotations already have
> @Target({ElementType.TYPE}) which already permits their usage in
> meta-annotations.
> The same is proposed for JPA 2.2, see
> https://github.com/javaee/jpa-spec/issues/43
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JDO-764) Allow JDO annotations to be used in meta-annotations
[
https://issues.apache.org/jira/browse/JDO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Jefferson updated JDO-764:
---
Description:
By default annotations are used directly in a persistable class. Java
additionally allows annotations to be formed of other annotations. This is
particularly useful where a user has a particular combination of annotations to
set on a class/field/method and wants to simply annotate with an abbreviated
form. For example, specifying attributes of an annotation
@PersistenceCapable(detachable="true", identityType="datastore",
embeddedOnly="true")
or formed of multiple annotations
@PersistenceCapable(detachable="true")
@Extension(vendorName="datanucleus", key="multitenancy-column-name",
value="TENANT")
These can be represented as meta-annotations like this
@Target(TYPE)
@Retention(RUNTIME)
@PersistenceCapable(detachable="true", identityType="datastore",
embeddedOnly="true")
public @interface DatastoreIdPersistable
{
}
@Target(TYPE)
@Retention(RUNTIME)
@PersistenceCapable(detachable="true")
@Extension(vendorName="datanucleus", key="multitenancy-column-name",
value="TENANT")
public @interface MultitenantPersistable
{
}
and the user can subsequently just annotate their persistable class as
@DatastoreIdPersistable
public class MyClass1 {...}
@MultitenantPersistable
public class MyClass2 {...}
The work required to support this in the JDO spec is simply to update the
following annotations to add @Target({ElementType.ANNOTATION_TYPE})
The annotations requiring this are
@Element, @EmbeddedId, @Key, @NotPersistent, @Order, @Persistent, @Serialized,
@Transactional, and @Value (all other annotations already have
@Target({ElementType.TYPE}) which already permits their usage in
meta-annotations.
The same is proposed for JPA 2.2, see
https://github.com/javaee/jpa-spec/issues/43
was:
By default annotations are used directly in a persistable class. Java
additionally allows annotations to be formed of other annotations. This is
particularly useful where a user has a particular combination of annotations to
set on a class/field/method and wants to simply annotate with an abbreviated
form. For example, specifying attributes of an annotation
@PersistenceCapable(detachable="true", identityType="datastore",
embeddedOnly="true")
or formed of multiple annotations
@PersistenceCapable(detachable="true")
@Extension(vendorName="datanucleus", key="multitenancy-column-name",
value="TENANT")
These can be represented as meta-annotations like this
@Target(TYPE)
@Retention(RUNTIME)
@PersistenceCapable(detachable="true", identityType="datastore",
embeddedOnly="true")
@interface @DatastoreIdPersistable
{
}
@Target(TYPE)
@Retention(RUNTIME)
@PersistenceCapable(detachable="true")
@Extension(vendorName="datanucleus", key="multitenancy-column-name",
value="TENANT")
@interface @MultitenantPersistable
{
}
and the user can subsequently just annotate their persistable class as
@DatastoreIdPersistable
public class MyClass1 {...}
@MultitenantPersistable
public class MyClass2 {...}
The work required to support this in the JDO spec is simply to update the
following annotations to add @Target({ElementType.ANNOTATION_TYPE})
The annotations requiring this are
@Element, @EmbeddedId, @Key, @NotPersistent, @Order, @Persistent, @Serialized,
@Transactional, and @Value (all other annotations already have
@Target({ElementType.TYPE}) which already permits their usage in
meta-annotations.
The same is proposed for JPA 2.2, see
https://github.com/javaee/jpa-spec/issues/43
> Allow JDO annotations to be used in meta-annotations
>
>
> Key: JDO-764
> URL: https://issues.apache.org/jira/browse/JDO-764
> Project: JDO
> Issue Type: Improvement
> Components: api, specification
>Affects Versions: JDO 3.1
>Reporter: Andy Jefferson
> Fix For: JDO 3.2
>
> Attachments: JDO-764.patch
>
>
> By default annotations are used directly in a persistable class. Java
> additionally allows annotations to be formed of other annotations. This is
> particularly useful where a user has a particular combination of annotations
> to set on a class/field/method and wants to simply annotate with an
> abbreviated form. For example, specifying attributes of an annotation
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> or formed of multiple annotations
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> These can be represented as meta-annotations like this
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> public @interface DatastoreIdPersistable
> {
> }
> @Target(TYPE)
> @Retention(RUNTIME)
[jira] [Commented] (JDO-764) Allow JDO annotations to be used in meta-annotations
[
https://issues.apache.org/jira/browse/JDO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16032931#comment-16032931
]
Andy Jefferson commented on JDO-764:
API updated with the patch. Spec updated to mirror the updates to the various
annotations.
Whether it needs any more than that in the spec is left for others to decide.
For reference I added a block to the DataNucleus documentation at
http://www.datanucleus.org/products/accessplatform_5_0/jdo/annotations.html#meta_annotations
explaining about meta-annotations and that JDO annotations can be utilised.
> Allow JDO annotations to be used in meta-annotations
>
>
> Key: JDO-764
> URL: https://issues.apache.org/jira/browse/JDO-764
> Project: JDO
> Issue Type: Improvement
> Components: api, specification
>Affects Versions: JDO 3.1
>Reporter: Andy Jefferson
> Fix For: JDO 3.2
>
> Attachments: JDO-764.patch
>
>
> By default annotations are used directly in a persistable class. Java
> additionally allows annotations to be formed of other annotations. This is
> particularly useful where a user has a particular combination of annotations
> to set on a class/field/method and wants to simply annotate with an
> abbreviated form. For example, specifying attributes of an annotation
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> or formed of multiple annotations
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> These can be represented as meta-annotations like this
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> @interface @DatastoreIdPersistable
> {
> }
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> @interface @MultitenantPersistable
> {
> }
> and the user can subsequently just annotate their persistable class as
> @DatastoreIdPersistable
> public class MyClass1 {...}
> @MultitenantPersistable
> public class MyClass2 {...}
> The work required to support this in the JDO spec is simply to update the
> following annotations to add @Target({ElementType.ANNOTATION_TYPE})
> The annotations requiring this are
> @Element, @EmbeddedId, @Key, @NotPersistent, @Order, @Persistent,
> @Serialized, @Transactional, and @Value (all other annotations already have
> @Target({ElementType.TYPE}) which already permits their usage in
> meta-annotations.
> The same is proposed for JPA 2.2, see
> https://github.com/javaee/jpa-spec/issues/43
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (JDO-764) Allow JDO annotations to be used in meta-annotations
[
https://issues.apache.org/jira/browse/JDO-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Jefferson updated JDO-764:
---
Attachment: JDO-764.patch
Patch providing the extra annotation config to allow use as meta-annotations
> Allow JDO annotations to be used in meta-annotations
>
>
> Key: JDO-764
> URL: https://issues.apache.org/jira/browse/JDO-764
> Project: JDO
> Issue Type: Improvement
> Components: api, specification
>Affects Versions: JDO 3.1
>Reporter: Andy Jefferson
> Fix For: JDO 3.2
>
> Attachments: JDO-764.patch
>
>
> By default annotations are used directly in a persistable class. Java
> additionally allows annotations to be formed of other annotations. This is
> particularly useful where a user has a particular combination of annotations
> to set on a class/field/method and wants to simply annotate with an
> abbreviated form. For example, specifying attributes of an annotation
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> or formed of multiple annotations
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> These can be represented as meta-annotations like this
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true", identityType="datastore",
> embeddedOnly="true")
> @interface @DatastoreIdPersistable
> {
> }
> @Target(TYPE)
> @Retention(RUNTIME)
> @PersistenceCapable(detachable="true")
> @Extension(vendorName="datanucleus", key="multitenancy-column-name",
> value="TENANT")
> @interface @MultitenantPersistable
> {
> }
> and the user can subsequently just annotate their persistable class as
> @DatastoreIdPersistable
> public class MyClass1 {...}
> @MultitenantPersistable
> public class MyClass2 {...}
> The work required to support this in the JDO spec is simply to update the
> following annotations to add @Target({ElementType.ANNOTATION_TYPE})
> The annotations requiring this are
> @Element, @EmbeddedId, @Key, @NotPersistent, @Order, @Persistent,
> @Serialized, @Transactional, and @Value (all other annotations already have
> @Target({ElementType.TYPE}) which already permits their usage in
> meta-annotations.
> The same is proposed for JPA 2.2, see
> https://github.com/javaee/jpa-spec/issues/43
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (JDO-764) Allow JDO annotations to be used in meta-annotations
Andy Jefferson created JDO-764:
--
Summary: Allow JDO annotations to be used in meta-annotations
Key: JDO-764
URL: https://issues.apache.org/jira/browse/JDO-764
Project: JDO
Issue Type: Improvement
Components: api
Reporter: Andy Jefferson
By default annotations are used directly in a persistable class. Java
additionally allows annotations to be formed of other annotations. This is
particularly useful where a user has a particular combination of annotations to
set on a class/field/method and wants to simply annotate with an abbreviated
form. For example, specifying attributes of an annotation
@PersistenceCapable(detachable="true", identityType="datastore",
embeddedOnly="true")
or formed of multiple annotations
@PersistenceCapable(detachable="true")
@Extension(vendorName="datanucleus", key="multitenancy-column-name",
value="TENANT")
These can be represented as meta-annotations like this
@Target(TYPE)
@Retention(RUNTIME)
@PersistenceCapable(detachable="true", identityType="datastore",
embeddedOnly="true")
@interface @DatastoreIdPersistable
{
}
@Target(TYPE)
@Retention(RUNTIME)
@PersistenceCapable(detachable="true")
@Extension(vendorName="datanucleus", key="multitenancy-column-name",
value="TENANT")
@interface @MultitenantPersistable
{
}
and the user can subsequently just annotate their persistable class as
@DatastoreIdPersistable
public class MyClass1 {...}
@MultitenantPersistable
public class MyClass2 {...}
The work required to support this in the JDO spec is simply to update the
following annotations to add @Target({ElementType.ANNOTATION_TYPE})
The annotations requiring this are
@Element, @EmbeddedId, @Key, @NotPersistent, @Order, @Persistent, @Serialized,
@Transactional, and @Value (all other annotations already have
@Target({ElementType.TYPE}) which already permits their usage in
meta-annotations.
The same is proposed for JPA 2.2, see
https://github.com/javaee/jpa-spec/issues/43
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (JDO-763) RI does not implement default of Query.setResult
[
https://issues.apache.org/jira/browse/JDO-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Jefferson reassigned JDO-763:
--
Assignee: (was: Andy Jefferson)
> RI does not implement default of Query.setResult
>
>
> Key: JDO-763
> URL: https://issues.apache.org/jira/browse/JDO-763
> Project: JDO
> Issue Type: Bug
> Components: tck
>Affects Versions: JDO 3.2
>Reporter: Michael Bouschen
> Fix For: JDO 3.2
>
> Attachments: SetResultDefault-patch.txt
>
>
> The JDO spec defines in chapter 14.6.9 "Specifying the Result of a Query
> (Projections, Aggregates)":
> Default Result
> If not specified, the result defaults to “distinct this as C” where C is the
> unqualified name of the candidate class. For example, the default result
> specification for a query where the candidate class is com.acme.hr.Employee
> is “distinct this as Employee”.
> The following query specifies a result class and assumes that the query
> result defaults to "distinct this as Person".
> Query query = pm.newQuery(Person.class, "lastname == 'emp1Last'");
> //query.setResult("distinct this as Person");
> query.setResultClass(PersonWrapper.class);
> Object results = query.execute();
> The above code results in org.datanucleus.exceptions.NucleusUserException:
> Query needs to return objects of type
> "org.apache.jdo.tck.query.api.SetResultDefault$PersonWrapper" but it was
> impossible to set the field "birthdate" type "java.util.Date". The field
> should have either a public set/put method, or be public.
> The query executes OK when explicitly specifying a result (see line in
> comments).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (JDO-763) RI does not implement default of Query.setResult
[
https://issues.apache.org/jira/browse/JDO-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15999709#comment-15999709
]
Andy Jefferson commented on JDO-763:
Not sure why this is assigned to me.
If the issue is to add a check to the TCK then just add it (hence not me).
If the issue is that DataNucleus handling needs to be something different to
what it is then somebody should raise an issue on DataNucleus issue tracker,
not here, since DataNucleus is not part of Apache JDO as such.
FWIW I added an issue
https://github.com/datanucleus/datanucleus-core/issues/211 for DN v5.1, not
sure if this is what your test needs to pass since I don't have the time to be
adding patches. I haven't backported this fix to DN v5.0 branch. Perhaps if
this test requires it then somebody can raise an equivalent issue in DN issue
tracking to backport it.
Thx
> RI does not implement default of Query.setResult
>
>
> Key: JDO-763
> URL: https://issues.apache.org/jira/browse/JDO-763
> Project: JDO
> Issue Type: Bug
> Components: tck
>Affects Versions: JDO 3.2
>Reporter: Michael Bouschen
>Assignee: Andy Jefferson
> Fix For: JDO 3.2
>
> Attachments: SetResultDefault-patch.txt
>
>
> The JDO spec defines in chapter 14.6.9 "Specifying the Result of a Query
> (Projections, Aggregates)":
> Default Result
> If not specified, the result defaults to “distinct this as C” where C is the
> unqualified name of the candidate class. For example, the default result
> specification for a query where the candidate class is com.acme.hr.Employee
> is “distinct this as Employee”.
> The following query specifies a result class and assumes that the query
> result defaults to "distinct this as Person".
> Query query = pm.newQuery(Person.class, "lastname == 'emp1Last'");
> //query.setResult("distinct this as Person");
> query.setResultClass(PersonWrapper.class);
> Object results = query.execute();
> The above code results in org.datanucleus.exceptions.NucleusUserException:
> Query needs to return objects of type
> "org.apache.jdo.tck.query.api.SetResultDefault$PersonWrapper" but it was
> impossible to set the field "birthdate" type "java.util.Date". The field
> should have either a public set/put method, or be public.
> The query executes OK when explicitly specifying a result (see line in
> comments).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[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] [Updated] (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 updated JDO-757:
---
Attachment: jdo-757-test.patch
Attached is a test for use of @Repeatable marked annotations, to check that it
is really invisible to a JDO provider (i.e no changes needed).
Spec and API are already updated in 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
> 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-757) Add @Repeatable to all annotations which can be repeated
Andy Jefferson created JDO-757:
--
Summary: 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
Fix For: JDO 3.2
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] [Commented] (JDO-756) Enhance PK to avoid LongIdentity/StringIdentity dependencies
[
https://issues.apache.org/jira/browse/JDO-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15462940#comment-15462940
]
Andy Jefferson commented on JDO-756:
> In Customer and Supplier classes: the id is long (not LongIdentity)
Well no. The Field/Property is of type long. The ID is of type LongIdentity
(because you didn't provide an ObjectIdClass).
The *only* reason there is a dependency on javax.jdo.identity.XXXIdentity is
because the example hasn't defined their own ObjectIdClass for Customer or
Supplier. If the user had a composite Id in Customer then they would put their
ObjectIdClass in the compound identity PK for BusinessRelation. So it is
totally consistent how compound identity relations are modelled currently.
Suggest that you go and sketch out Supplier and Customer each using multiple PK
fields (and the subsequent identity) and see how that fits, and see why it is
done as it is.
> Enhance PK to avoid LongIdentity/StringIdentity dependencies
>
>
> Key: JDO-756
> URL: https://issues.apache.org/jira/browse/JDO-756
> Project: JDO
> Issue Type: Improvement
>Reporter: joseaio
> Fix For: JDO 3.2
>
>
> Please see: JDO Guides : M-N Attributed Relation
> http://www.datanucleus.org/products/accessplatform_3_1/guides/jdo/many_many_attributed/index.html
> public class BusinessRelation{
> · private Customer customer; // PK
> · private Supplier supplier; // PK
> BusinessRelation.PK requires:
> · public LongIdentity customer; // LongIdentity dependency
> · public LongIdentity supplier; // LongIdentity dependency
> In Customer and Supplier classes: the id is long (not LongIdentity)
> · private long id; // PK
>
> I think more convenient enhance BusinessRelation.PK to allow long types (and
> remove LongIdentity/***Identity dependencies):
> BusinessRelation.PK
> · public long customer; // Use long as Customer.id field
> · public long supplier; // Use long as Supplier.id field
> note: the same rule for other basic types (String, Dates, Integer, Long,
> Byte...)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[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=15429359#comment-15429359 ] Andy Jefferson commented on JDO-735: Perhaps Extent should also be AutoCloseable? Perhaps Query should have isClosed() added and throw JDOUserException if a method called when already closed (for consistency with PersistenceManager). And ditto Extent if the first question is affirmative. > 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)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15346784#comment-15346784 ] Andy Jefferson commented on JDO-751: 1. I said DN equates a transient to null (nothing else reasonable to put it as IMHO - the log has a message about it). This is fine when comparing null with persistent (the other test), since it doesn't equate. In your test it is not fine for the reason I mentioned. > Support for Java8 Optional > -- > > Key: JDO-751 > URL: https://issues.apache.org/jira/browse/JDO-751 > Project: JDO > Issue Type: New Feature > Components: specification, tck >Reporter: Andy Jefferson > Fix For: JDO 3.2 > > Attachments: JDO-751-tck-patch-v4.txt > > > java.util.Optional provides a feature that is available in other languages. > Since JDO 3.2 will be for Java8+ then it makes sense to add support for this > as a "supported persistable type" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15337814#comment-15337814 ] Andy Jefferson commented on JDO-751: Comments from cursory scan of the patch 1. You use a transient PC object passed in to a query. As per JDO spec assertion 14.6.2-44 "Comparisons between persistent and non-persistent instances return not equal". Do not use a transient PC object (which has no "id" as such), use detached or persistent-clean if you want to judge equality. 2. Using date equality is error prone since some datastores (RDBMS) don't store the precise millisecs so any comparison may work or may not depending on the precise nature of JDBC driver, and RDBMS handling. 3. Using optional.optional.xxx is getting some way from what I would term "common use-case" > Support for Java8 Optional > -- > > Key: JDO-751 > URL: https://issues.apache.org/jira/browse/JDO-751 > Project: JDO > Issue Type: New Feature > Components: specification, tck >Reporter: Andy Jefferson > Fix For: JDO 3.2 > > Attachments: JDO-751-tck-patch-v4.txt > > > java.util.Optional provides a feature that is available in other languages. > Since JDO 3.2 will be for Java8+ then it makes sense to add support for this > as a "supported persistable type" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (JDO-753) Review Tomcat port configuration
[ https://issues.apache.org/jira/browse/JDO-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson closed JDO-753. -- Resolution: Won't Fix Fix Version/s: (was: JDO 3 update 1 (3.0.1)) No idea what this is about but since you haven't clarified what you mean, we have to assume that this is misposted/spam. Your related URL doesn't work either. > Review Tomcat port configuration > > > Key: JDO-753 > URL: https://issues.apache.org/jira/browse/JDO-753 > Project: JDO > Issue Type: Bug > Components: site and infrastructure >Affects Versions: JDO 3 update 1 (3.0.1) > Environment: Linux-based hosting: > Java Servlets (JSP via Tomcat engine) > Apache ASP > Python > PHP5 > JSON PHP Extension >Reporter: Roger Mbiama > Labels: build > Original Estimate: 504h > Remaining Estimate: 504h > > /* > * new additional configuration > */ > > connectionTimeout="2" > redirectPort="8443/smb" /> > > >unpackWARs="true" > autoDeploy="true" xmlValidation="true" > xmlNamespaceAware="false"> > domain.net > > > > org.apache.tomcat/tomcat-dbcp/9.0.0.M6.location = > /var/www/vhostst/domain.net/httpdocs/repositoryDB -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JDO-753) Review Tomcat port configuration
[ https://issues.apache.org/jira/browse/JDO-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15315907#comment-15315907 ] Andy Jefferson commented on JDO-753: Hello, care to share with us what relevance this has to v3.0.1 of the JDO API?! I don't see the relevance of Tomcat to an Apache project that simply generates a specification document, and API, and a TCK for that API. Where is Tomcat involved in this? Do you perhaps have the wrong project? > Review Tomcat port configuration > > > Key: JDO-753 > URL: https://issues.apache.org/jira/browse/JDO-753 > Project: JDO > Issue Type: Bug > Components: site and infrastructure >Affects Versions: JDO 3 update 1 (3.0.1) > Environment: Linux-based hosting: > Java Servlets (JSP via Tomcat engine) > Apache ASP > Python > PHP5 > JSON PHP Extension >Reporter: Roger Mbiama > Labels: build > Fix For: JDO 3 update 1 (3.0.1) > > Original Estimate: 504h > Remaining Estimate: 504h > > /* > * new additional configuration > */ > > connectionTimeout="2" > redirectPort="8443/smb" /> > > >unpackWARs="true" > autoDeploy="true" xmlValidation="true" > xmlNamespaceAware="false"> > domain.net > > > > org.apache.tomcat/tomcat-dbcp/9.0.0.M6.location = > /var/www/vhostst/domain.net/httpdocs/repositoryDB -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JDO-747) Behavior of delete() with multiple concurrent Transactions
[
https://issues.apache.org/jira/browse/JDO-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15222121#comment-15222121
]
Andy Jefferson commented on JDO-747:
Perhaps the requester of this "feature" can work on implementation in the RI?
I'm available to offer help in where to find things in the source code etc but
have not been following what this is all about, and makes sense for other
people to develop the RI not just me.
> Behavior of delete() with multiple concurrent Transactions
> --
>
> Key: JDO-747
> URL: https://issues.apache.org/jira/browse/JDO-747
> Project: JDO
> Issue Type: Improvement
> Components: specification
>Affects Versions: JDO 3.1
>Reporter: Tilmann Zäschke
>Priority: Minor
> Labels: concurrency, delete, documentation, refresh(),
> specification
> Fix For: JDO 3.2
>
> Attachments: JDO-StateTransition-logs-2015-12-04.zip,
> OptimisticCheckConsistency.java, OptimisticFailurePatch_JDO747.txt,
> StateTransitionPatch_JDO747_v4.txt
>
>
> In the Spec I could not find any statement regarding on how a transaction
> should behave if an object is deleted in a different concurrent transaction.
> Related Sections are Section 5.8 (how different methods should behave for
> different object states) and Section 12.6.1 (the behavior of refresh() and
> related methods).
> For example I wonder about the following situations. Suppose I have two
> optimistic sessions, pm1 and pm2, both access the same object. pm1 deletes
> the object and commits. Then what happens in pm2 if:
> 1. pm2 deletes the object and tries to commit, should that work? It's
>wouldn't be a real conflict if both delete it.
> 2. pm2 modifies the object (make dirty) and calls {{refresh()}}. Should I
>get an {{ObjectNotFound}} exception?
> 3. pm2 deletes the object and calls {{refresh()}}. According to the spec,
>{{refresh()}} should not change the object's state. But should it
>still fail with {{ObjectNotFound}}? If refresh should fail, how can I
>ever recover from such a situation, because I can't undelete the
>object?
> Is there a common understanding how this should work?
> IF there an external definition JDO relies on, then I think a reference to an
> external document might useful.
> If not, should the Spec define concurrent behavior?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138522#comment-15138522 ] Andy Jefferson commented on JDO-751: >From Apache JDO "minutes" Q. Does it make sense to support Optional as a persistent type? It would need to map to a nullable datastore value. So Optional can be the type of a persistent field iff T can be the type of a persistent field. Does it make sense to support Optional as a first class object? If an Employee has a field Optional can the field be treated as first class? Q. Could Employee.getDepartment() return an Optional? Answer : yes to both. A user can have fields of types like Optional, Optional and would expect these to be mapped in the datastore to a column that accepts NULLs, and of the equivalent type of T. Similarly they could have a 1-1 relation via a field of type Optional. The other aspect of this would be in terms of JDOQL and queryability of such fields. Following the idea that JDOQL attempts to have Java syntax then we should have methods optionalField.isPresent() returning a BooleanExpression optionalField.get() returning an expression of the type of the T type, so StringExpression, DateExpression, etc. The alternative to this is just to let the user do "== NULL" to check if a value is present. Comments? > Support for Java8 Optional > -- > > Key: JDO-751 > URL: https://issues.apache.org/jira/browse/JDO-751 > Project: JDO > Issue Type: New Feature > Components: specification, tck >Reporter: Andy Jefferson > > java.util.Optional provides a feature that is available in other languages. > Since JDO 3.2 will be for Java8+ then it makes sense to add support for this > as a "supported persistable type" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15138522#comment-15138522 ] Andy Jefferson edited comment on JDO-751 at 2/9/16 8:25 AM: >From Apache JDO "minutes" Q. Does it make sense to support Optional as a persistent type? It would need to map to a nullable datastore value. So Optional can be the type of a persistent field iff T can be the type of a persistent field. Does it make sense to support Optional as a first class object? If an Employee has a field Optional can the field be treated as first class? Q. Could Employee.getDepartment() return an Optional? Answer : yes to both. A user can have fields of types like Optional, Optional and would expect these to be mapped in the datastore to a column that accepts NULLs, and of the equivalent type of T. Similarly they could have a 1-1 relation via a field of type Optional (i.e creating the FK to the table of MyOtherType). The other aspect of this would be in terms of JDOQL and queryability of such fields. Following the idea that JDOQL attempts to have Java syntax then we should have methods optionalField.isPresent() returning a BooleanExpression optionalField.get() returning an expression of the type of the T type, so StringExpression, DateExpression, etc. The alternative to this is just to let the user do "== NULL" to check if a value is present. Comments? was (Author: andy): >From Apache JDO "minutes" Q. Does it make sense to support Optional as a persistent type? It would need to map to a nullable datastore value. So Optional can be the type of a persistent field iff T can be the type of a persistent field. Does it make sense to support Optional as a first class object? If an Employee has a field Optional can the field be treated as first class? Q. Could Employee.getDepartment() return an Optional? Answer : yes to both. A user can have fields of types like Optional, Optional and would expect these to be mapped in the datastore to a column that accepts NULLs, and of the equivalent type of T. Similarly they could have a 1-1 relation via a field of type Optional. The other aspect of this would be in terms of JDOQL and queryability of such fields. Following the idea that JDOQL attempts to have Java syntax then we should have methods optionalField.isPresent() returning a BooleanExpression optionalField.get() returning an expression of the type of the T type, so StringExpression, DateExpression, etc. The alternative to this is just to let the user do "== NULL" to check if a value is present. Comments? > Support for Java8 Optional > -- > > Key: JDO-751 > URL: https://issues.apache.org/jira/browse/JDO-751 > Project: JDO > Issue Type: New Feature > Components: specification, tck >Reporter: Andy Jefferson > > java.util.Optional provides a feature that is available in other languages. > Since JDO 3.2 will be for Java8+ then it makes sense to add support for this > as a "supported persistable type" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JDO-749) Support for java.time types, and querying using associated methods
[ https://issues.apache.org/jira/browse/JDO-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15108420#comment-15108420 ] Andy Jefferson commented on JDO-749: Java8 Expressions now added to jdo-api > Support for java.time types, and querying using associated methods > -- > > Key: JDO-749 > URL: https://issues.apache.org/jira/browse/JDO-749 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Andy Jefferson > Fix For: JDO 3.2 > > > Refer to an associated issue for JPA for what support should look like > https://java.net/jira/browse/JPA_SPEC-63 > The methods that should be supported in queries would initially be > LocalDateTime : getDayOfMonth, getMonth, getYear, getHour, getMinute, > getSecond > LocalTime : getHour, getMinute, getSecond > LocalDate : getDayOfMonth, getMonth, getYear > These would need to be part of JDOQL string-based, as well as the > JDOQLTypedQuery (hence have equivalent Expression classes). > Note that all of these are already implemented in DataNucleus, and there are > JDOQLTypedQuery expression classes available. > Timing of this simply depends on the JRE that the next release of JDO is > targetted at, since this needs Java 8. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JDO-750) Change development environment to JDK 1.8
[ https://issues.apache.org/jira/browse/JDO-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15108410#comment-15108410 ] Andy Jefferson commented on JDO-750: SVN now updated to use Java8. Note that I could not find anywhere in the JDO spec that defines the JRE required for use of JDO. Perhaps it ought to be added in Chapter 1, where it talks of Scope, Target Audience etc ? > Change development environment to JDK 1.8 > - > > Key: JDO-750 > URL: https://issues.apache.org/jira/browse/JDO-750 > Project: JDO > Issue Type: Task > Components: api, tck >Affects Versions: JDO 3.2 >Reporter: Michael Bouschen > Fix For: JDO 3.2 > > > The idea is that we continue to support JDK 1.7 runtime, but the development > requires JDK 1.8. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JDO-750) Change development environment to JDK 1.8
[ https://issues.apache.org/jira/browse/JDO-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102229#comment-15102229 ] Andy Jefferson commented on JDO-750: No objections from me. DN 4.2 supports all features of JDO.next prior to the time types, and allows java7+. DN 5.0 is proposed to use java8 minimum to match JDO.next requiring java8. Consequently anyone using java7 can use DN 4.2 (including new features) or DN 4.1 (with JDO 3.1), and anyone using java8 can use DN 4.1/2 (JDO3.1) or DN5.0 (JDO.next). > Change development environment to JDK 1.8 > - > > Key: JDO-750 > URL: https://issues.apache.org/jira/browse/JDO-750 > Project: JDO > Issue Type: Task > Components: api, tck >Affects Versions: JDO 3.2 >Reporter: Michael Bouschen > Fix For: JDO 3.2 > > > The idea is that we continue to support JDK 1.7 runtime, but the development > requires JDK 1.8. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JDO-749) Support for java.time types, and querying using associated methods
[ https://issues.apache.org/jira/browse/JDO-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15005255#comment-15005255 ] Andy Jefferson commented on JDO-749: Actually, after doing a few tests with Java7 and Java8, we cannot simply add Java8 related classes to jdo-api compile to 1.8 and run with 1.7, since some operations have a check on major.minor version and it finds the jdo-api with major.minor as 52.0. Ways around this are 1. Have 2 jdo-api jars. One for java7 and one for java8 (with the java.time support), and the user pulls in the one they require. 2. Just move to java8 minimum > Support for java.time types, and querying using associated methods > -- > > Key: JDO-749 > URL: https://issues.apache.org/jira/browse/JDO-749 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Andy Jefferson > Fix For: JDO 3.2 > > > Refer to an associated issue for JPA for what support should look like > https://java.net/jira/browse/JPA_SPEC-63 > The methods that should be supported in queries would initially be > LocalDateTime : getDayOfMonth, getMonth, getYear, getHour, getMinute, > getSecond > LocalTime : getHour, getMinute, getSecond > LocalDate : getDayOfMonth, getMonth, getYear > These would need to be part of JDOQL string-based, as well as the > JDOQLTypedQuery (hence have equivalent Expression classes). > Note that all of these are already implemented in DataNucleus, and there are > JDOQLTypedQuery expression classes available. > Timing of this simply depends on the JRE that the next release of JDO is > targetted at, since this needs Java 8. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (JDO-749) Support for java.time types, and querying using associated methods
[ https://issues.apache.org/jira/browse/JDO-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15005255#comment-15005255 ] Andy Jefferson edited comment on JDO-749 at 11/14/15 10:37 AM: --- Actually, after doing a few tests with Java7 and Java8, we cannot simply add Java8 related classes to jdo-api compile to 1.8 and run with 1.7, since some operations have a check on major.minor version and it finds the jdo-api with major.minor as 52.0. Ways around this are 1. Have 2 jdo-api jars. One for java7 and one for java8 (with the java.time support), and the user pulls in the one they require. 2. Just move to java8 minimum Note : this applies solely to the use of Java8 types in the JDOQLTypedQuery. Java8 types can still be used with JDO 3.2 without any change to "jdo-api" for all other features (persistence, standard JDOQL). was (Author: andy): Actually, after doing a few tests with Java7 and Java8, we cannot simply add Java8 related classes to jdo-api compile to 1.8 and run with 1.7, since some operations have a check on major.minor version and it finds the jdo-api with major.minor as 52.0. Ways around this are 1. Have 2 jdo-api jars. One for java7 and one for java8 (with the java.time support), and the user pulls in the one they require. 2. Just move to java8 minimum > Support for java.time types, and querying using associated methods > -- > > Key: JDO-749 > URL: https://issues.apache.org/jira/browse/JDO-749 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Andy Jefferson > Fix For: JDO 3.2 > > > Refer to an associated issue for JPA for what support should look like > https://java.net/jira/browse/JPA_SPEC-63 > The methods that should be supported in queries would initially be > LocalDateTime : getDayOfMonth, getMonth, getYear, getHour, getMinute, > getSecond > LocalTime : getHour, getMinute, getSecond > LocalDate : getDayOfMonth, getMonth, getYear > These would need to be part of JDOQL string-based, as well as the > JDOQLTypedQuery (hence have equivalent Expression classes). > Note that all of these are already implemented in DataNucleus, and there are > JDOQLTypedQuery expression classes available. > Timing of this simply depends on the JRE that the next release of JDO is > targetted at, since this needs Java 8. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14903067#comment-14903067 ] Andy Jefferson commented on JDO-652: If you want a better query API utilising Java 8 language features (and there are clearly lots of ideas around about how it could look, e.g Jinq) i'd encourage you to develop a proof of concept and ask for ideas as your concept starts to take shape - having something usable to visualise it is the best way of getting feedback. Feel free to clone the DN datanucleus-api-jdo and datanucleus-java8 plugins so it is readily visible, and if it comes to something it could initially become part of DN and then later JDO? i.e the same steps as we went through with the JDOQLTypedQuery. > 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 > Fix For: JDO 3.2 > > Attachments: 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 (v6.3.4#6332)
[jira] [Commented] (JDO-749) Support for java.time types, and querying using associated methods
[ https://issues.apache.org/jira/browse/JDO-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14902332#comment-14902332 ] Andy Jefferson commented on JDO-749: So the real question is, is everyone ok with updating the (minimum) JDK that Apache JDO needs to be developed with to 1.8? (after all 1.7 is past EOL). With that we can add support for JDK 1.8 types in the API (for JDO 3.2), add tests for them in the TCK, whilst still releasing jars that have 1.7 1.7 > Support for java.time types, and querying using associated methods > -- > > Key: JDO-749 > URL: https://issues.apache.org/jira/browse/JDO-749 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Andy Jefferson > > Refer to an associated issue for JPA for what support should look like > https://java.net/jira/browse/JPA_SPEC-63 > The methods that should be supported in queries would initially be > LocalDateTime : getDayOfMonth, getMonth, getYear, getHour, getMinute, > getSecond > LocalTime : getHour, getMinute, getSecond > LocalDate : getDayOfMonth, getMonth, getYear > These would need to be part of JDOQL string-based, as well as the > JDOQLTypedQuery (hence have equivalent Expression classes). > Note that all of these are already implemented in DataNucleus, and there are > JDOQLTypedQuery expression classes available. > Timing of this simply depends on the JRE that the next release of JDO is > targetted at, since this needs Java 8. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JDO-749) Support for java.time types, and querying using associated methods
[ https://issues.apache.org/jira/browse/JDO-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14902561#comment-14902561 ] Andy Jefferson commented on JDO-749: I can add Java 8 classes to a project with those maven compile directives, and have JAVA_HOME set to JDK 1.8 (so using a JDK 1.8 compiler), and do a mvn clean install, and it compiles/installs. At runtime if running with JRE 1.8 and I make use of a LocalXXX class it works fine, and if I'm at runtime with JRE 1.7 then I won't have any LocalXXX class in my persistence capable classes so no problem there either. Since there are no explicit references to the JDK 1.8 classes in any class that a JRE 1.7 user will be instantiating then there is no problem at runtime when using JRE 1.7 (i.e this is a *specific case* of using JDK 1.8 classes without referring to them in non JRE 1.8 code). Admittedly some IDE's have issues with such a setup and the better solution is to go to JRE 1.8 for all; question of timing. And about yet another 'redesign' of the query API, we have waited nearly 3 years for this one from the provision of the DN TypesafeQuery API with little input from others. Bear in mind that I wouldn't be contributing much time, so if you want it then you need to provide time/ideas/implementations/tests. > Support for java.time types, and querying using associated methods > -- > > Key: JDO-749 > URL: https://issues.apache.org/jira/browse/JDO-749 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Andy Jefferson > > Refer to an associated issue for JPA for what support should look like > https://java.net/jira/browse/JPA_SPEC-63 > The methods that should be supported in queries would initially be > LocalDateTime : getDayOfMonth, getMonth, getYear, getHour, getMinute, > getSecond > LocalTime : getHour, getMinute, getSecond > LocalDate : getDayOfMonth, getMonth, getYear > These would need to be part of JDOQL string-based, as well as the > JDOQLTypedQuery (hence have equivalent Expression classes). > Note that all of these are already implemented in DataNucleus, and there are > JDOQLTypedQuery expression classes available. > Timing of this simply depends on the JRE that the next release of JDO is > targetted at, since this needs Java 8. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JDO-749) Support for java.time types, and querying using associated methods
[ https://issues.apache.org/jira/browse/JDO-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14875955#comment-14875955 ] Andy Jefferson commented on JDO-749: The XXXExpression classes could be included in the JDO API, but with the proviso that the JDO API would need to be built using JDK 1.8 (though runnable for JRE 1.7+). > Support for java.time types, and querying using associated methods > -- > > Key: JDO-749 > URL: https://issues.apache.org/jira/browse/JDO-749 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Andy Jefferson > > Refer to an associated issue for JPA for what support should look like > https://java.net/jira/browse/JPA_SPEC-63 > The methods that should be supported in queries would initially be > LocalDateTime : getDayOfMonth, getMonth, getYear, getHour, getMinute, > getSecond > LocalTime : getHour, getMinute, getSecond > LocalDate : getDayOfMonth, getMonth, getYear > These would need to be part of JDOQL string-based, as well as the > JDOQLTypedQuery (hence have equivalent Expression classes). > Note that all of these are already implemented in DataNucleus, and there are > JDOQLTypedQuery expression classes available. > Timing of this simply depends on the JRE that the next release of JDO is > targetted at, since this needs Java 8. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JDO-749) Support for java.time types, and querying using associated methods
Andy Jefferson created JDO-749: -- Summary: Support for java.time types, and querying using associated methods Key: JDO-749 URL: https://issues.apache.org/jira/browse/JDO-749 Project: JDO Issue Type: New Feature Components: api, specification, tck Reporter: Andy Jefferson Refer to an associated issue for JPA for what support should look like https://java.net/jira/browse/JPA_SPEC-63 The methods that should be supported in queries would initially be LocalDateTime : getDayOfMonth, getMonth, getYear, getHour, getMinute, getSecond LocalTime : getHour, getMinute, getSecond LocalDate : getDayOfMonth, getMonth, getYear These would need to be part of JDOQL string-based, as well as the JDOQLTypedQuery (hence have equivalent Expression classes). Note that all of these are already implemented in DataNucleus, and there are JDOQLTypedQuery expression classes available. Timing of this simply depends on the JRE that the next release of JDO is targetted at, since this needs Java 8. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JDO-734) Ability to save a (created) query as a named query for later use
[
https://issues.apache.org/jira/browse/JDO-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Jefferson resolved JDO-734.
Resolution: Fixed
> Ability to save a (created) query as a named query for later use
>
>
> Key: JDO-734
> URL: https://issues.apache.org/jira/browse/JDO-734
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
>Reporter: Andy Jefferson
> Fix For: JDO 3.2
>
> Attachments: JDO-734.api.patch, SaveAsNamedQuery.java
>
>
> When a user goes to the trouble of creating a query to retrieve some
> information it is a common enough scenario that this will need to be
> performed again during the application lifetime. Being able to save a query
> (once created) as a named query (in the PMF) would mean that applications can
> skip the generation step off for subsequent runs.
> Suggested API change would be to add a single method to Query.
> Query q = pm1.newQuery("SELECT p FROM Person p WHERE firstName == :param");
> q.saveAsNamedQuery("PeopleWithName");
> q.execute("John");
> ... (some time later)
> Query q = pm2.newNamedQuery(Person.class, "PeopleWithName");
> q.execute("Brian");
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14736476#comment-14736476 ] Andy Jefferson commented on JDO-652: The other option to 1. spec is to create a new chapter 15 straight after "14. Query". The only problem is, I've no idea how these JDO_master.odm and the various chapters are linked, so if people prefer that then maybe someone who knows can create a start point for this new Chapter and I'll update it with the necessary description > 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 > Fix For: JDO 3.2 > > Attachments: 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 (v6.3.4#6332)
[jira] [Commented] (JDO-748) Tyops in spec and dead link on homepage
[
https://issues.apache.org/jira/browse/JDO-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14737361#comment-14737361
]
Andy Jefferson commented on JDO-748:
Ch12 updated in SVN hopefully fixing those formatting errors.
The link on the website works for me. Maybe Apache was in an "unavailable"
period when you tried.
> Tyops in spec and dead link on homepage
> ---
>
> Key: JDO-748
> URL: https://issues.apache.org/jira/browse/JDO-748
> Project: JDO
> Issue Type: Improvement
> Components: site and infrastructure, specification
>Reporter: Tilmann Zäschke
>Priority: Trivial
> Labels: documentation, homepage
> Fix For: JDO 3.2
>
>
> Section 12.10 uses a wrong font:
> 1) The last paragraph mentions "PersistenceManager.setMultithreaded"
> and "getMultithreaded". Both should presumably use code-font and possibly
> have trailing '()' added.
> Section 12.11 of the spec contains some typos:
> 3) The 3rd paragraph starts with a '.' which should presumably be at the end
> of paragraph 2.
> 4) The code after paragraph 5 should use a code font
> 5) The code after paragraph 6 should use a code font
> On the home page (https://db.apache.org/jdo/svn.html) in the second section
> ("Web Access to Subversion"):
> 6) The link for browsing SVN (http://svn.apache.org/viewcvs/db/jdo) reports
> "Not Found The requested URL /viewcvs/db/jdo was not found on this
> server."
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (JDO-748) Tyops in spec and dead link on homepage
[
https://issues.apache.org/jira/browse/JDO-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Jefferson resolved JDO-748.
Resolution: Fixed
Fix Version/s: JDO 3.2
> Tyops in spec and dead link on homepage
> ---
>
> Key: JDO-748
> URL: https://issues.apache.org/jira/browse/JDO-748
> Project: JDO
> Issue Type: Improvement
> Components: site and infrastructure, specification
>Reporter: Tilmann Zäschke
>Priority: Trivial
> Labels: documentation, homepage
> Fix For: JDO 3.2
>
>
> Section 12.10 uses a wrong font:
> 1) The last paragraph mentions "PersistenceManager.setMultithreaded"
> and "getMultithreaded". Both should presumably use code-font and possibly
> have trailing '()' added.
> Section 12.11 of the spec contains some typos:
> 3) The 3rd paragraph starts with a '.' which should presumably be at the end
> of paragraph 2.
> 4) The code after paragraph 5 should use a code font
> 5) The code after paragraph 6 should use a code font
> On the home page (https://db.apache.org/jdo/svn.html) in the second section
> ("Web Access to Subversion"):
> 6) The link for browsing SVN (http://svn.apache.org/viewcvs/db/jdo) reports
> "Not Found The requested URL /viewcvs/db/jdo was not found on this
> server."
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14735201#comment-14735201 ] Andy Jefferson edited comment on JDO-652 at 9/8/15 5:53 PM: What remains on this issue : 1. spec : I don't mind contributing some text. The problem is that most of Ch14 is based around javax.jdo.Query. What I suggest would be updates to 14.1 to mention about JDOQLTypedQuery, an update to Ch14.5 to add the newJDOQLTypedQuery() method. Then insert a new section 14.10 before "Examples" to discuss solely the JDOQLTypedQuery interface. Finally update the "Examples" section to add some examples at the end. Other ideas? Alternately put the new section after examples, and have its examples inline with the various method descriptions. 2. tck : this needs tests. I am not the best person to write these since I've written the majority of the API, and the implementation. Volunteer? was (Author: andy): What remains on this issue : 1. spec : I don't mind contributing some text. What I suggest would be an update to Ch14.5 to add the newJDOQLTypedQuery() method. Then insert a new section 14.6 before "SQL Queries" to discuss solely the JDOQLTypedQuery interface. Finally update the "Examples" section to add some examples at the end. Other ideas? 2. tck : this needs tests. I am not the best person to write these since I've written the majority of the API, and the implementation. Volunteer? > 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 > Fix For: JDO 3.2 > > Attachments: 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 (v6.3.4#6332)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14735201#comment-14735201 ] Andy Jefferson commented on JDO-652: What remains on this issue : 1. spec : I don't mind contributing some text. What I suggest would be an update to Ch14.5 to add the newJDOQLTypedQuery() method. Then insert a new section 14.6 before "SQL Queries" to discuss solely the JDOQLTypedQuery interface. Finally update the "Examples" section to add some examples at the end. Other ideas? 2. tck : this needs tests. I am not the best person to write these since I've written the majority of the API, and the implementation. Volunteer? > 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 > Fix For: JDO 3.2 > > Attachments: 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 (v6.3.4#6332)
[jira] [Commented] (JDO-734) Ability to save a (created) query as a named query for later use
[
https://issues.apache.org/jira/browse/JDO-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14735308#comment-14735308
]
Andy Jefferson commented on JDO-734:
Spec update is in SVN as is this test. Any more to do? otherwise mark as
resolved
> Ability to save a (created) query as a named query for later use
>
>
> Key: JDO-734
> URL: https://issues.apache.org/jira/browse/JDO-734
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
>Reporter: Andy Jefferson
> Fix For: JDO 3.2
>
> Attachments: JDO-734.api.patch, SaveAsNamedQuery.java
>
>
> When a user goes to the trouble of creating a query to retrieve some
> information it is a common enough scenario that this will need to be
> performed again during the application lifetime. Being able to save a query
> (once created) as a named query (in the PMF) would mean that applications can
> skip the generation step off for subsequent runs.
> Suggested API change would be to add a single method to Query.
> Query q = pm1.newQuery("SELECT p FROM Person p WHERE firstName == :param");
> q.saveAsNamedQuery("PeopleWithName");
> q.execute("John");
> ... (some time later)
> Query q = pm2.newNamedQuery(Person.class, "PeopleWithName");
> q.execute("Brian");
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JDO-734) Ability to save a (created) query as a named query for later use
[ https://issues.apache.org/jira/browse/JDO-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Jefferson updated JDO-734: --- Attachment: SaveAsNamedQuery.java Test for saveAsNamedQuery() unless someone has a better suggestion ... Ability to save a (created) query as a named query for later use Key: JDO-734 URL: https://issues.apache.org/jira/browse/JDO-734 Project: JDO Issue Type: New Feature Components: api, specification, tck Reporter: Andy Jefferson Fix For: JDO 3.2 Attachments: JDO-734.api.patch, SaveAsNamedQuery.java When a user goes to the trouble of creating a query to retrieve some information it is a common enough scenario that this will need to be performed again during the application lifetime. Being able to save a query (once created) as a named query (in the PMF) would mean that applications can skip the generation step off for subsequent runs. Suggested API change would be to add a single method to Query. Query q = pm1.newQuery(SELECT p FROM Person p WHERE firstName == :param); q.saveAsNamedQuery(PeopleWithName); q.execute(John); ... (some time later) Query q = pm2.newNamedQuery(Person.class, PeopleWithName); q.execute(Brian); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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-tabpanelfocusedCommentId=14712782#comment-14712782 ] Andy Jefferson commented on JDO-735: Test now in SVN, along with another for AutoCloseable, and previous test is removed from pm.conf 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 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)
[jira] [Updated] (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:all-tabpanel ] Andy Jefferson updated JDO-735: --- Attachment: CloseWithActiveTxRollsBack.java Test for call of close() when active tx, to check that it rolls back. This should REPLACE CloseThrowsExceptionWhenActiveTx.java 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 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)
