[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)
Re: TCK : TreeSetCollections CHALLENGE
> Upon inspection of the TCK orm.xml files I find the embedded fields such as > TreeSetCollections.TreeSetOfObject1 are supposed to be embedded in a join > table, yet have no block, though they do for the other java.util > type tests. FWIW The same comment applies to the ORM files for ArrayList (app id and ds id). List, LinkedList, Vector all have the block, whereas ArrayList doesn't. The requisite schema for ArrayList and TreeSet likewise don't have the embedded columns needed, so that would need updating too. Currently, for those cases, it seems to be simply ignoring the embedded flag and storing the SimpleClass in its own table with FK across to it from the join table. -- Andy DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
Re: JDO TCK Conference Call Thursday March 31 11 PM PDT 20 CEST
> 2. JDK 18 General Availability, and oracle-actions/setup-java see email Not that it directly impacts on Apache JDO building, but DataNucleus v6.0 currently works for JDKs 8 through 17. This range is limited by the internal repackaged version of the ASM bytecode library used (currently using v9.1). There is a v9.2 available that adds support for JDK 18, but since this JDK is not an LTS release I'm not contemplating it anytime soon; maybe when there is a version of ASM for JDK 19. Regards -- Andy DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
TCK : TreeSetCollections CHALLENGE
Hi, after reworking some DN code and rerunning the TCK I came across a situation where TestTreeSetCollections was failing (for app id), yet TestHashSetCollections/TestSetCollections were passing (which was strange considering the innocuous change I've been making). That, on its own, doesn't say whether the problem is mine, or the TCKs. Upon inspection of the TCK orm.xml files I find the embedded fields such as TreeSetCollections.TreeSetOfObject1 are supposed to be embedded in a join table, yet have no block, though they do for the other java.util type tests. See TreeSet https://github.com/apache/db-jdo/blob/main/tck/src/main/resources/orm/ applicationidentity/org/apache/jdo/tck/pc/fieldtypes/TreeSetCollections- standard.orm#L30 compared to HashSet https://github.com/apache/db-jdo/blob/main/tck/src/main/resources/orm/ applicationidentity/org/apache/jdo/tck/pc/fieldtypes/HashSetCollections- standard.orm#L30 and Set https://github.com/apache/db-jdo/blob/main/tck/src/main/resources/orm/ applicationidentity/org/apache/jdo/tck/pc/fieldtypes/SetCollections- standard.orm#L30 Any comments? Regards -- Andy DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
[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)
Re: Minutes [corrected]: JDO TCK Conference Call Thursday Dec 16 11 AM PST 20 CET
> 1. Log4j issue CVE-2021-44228 JDO-800 "Update Log4j Version" > https://issues.apache.org/jira/browse/JDO-800 > TCK pom has been updated to log4j 2.16.0. > What are the DataNucleus versions that we should use that have been or will > be updated with the latest log4j releases? The exact same ones as you are using. DN does not make direct use of any Log4j internal API etc, just gets a LogManager and a Logger from that. The API for those calls is unchanged by this "issue". Consequently it is only at RUNTIME that such an issue could be exploited, and the user (of DN) chooses what version of Log4j to make use of at runtime. No plans to update our pom (for v5.x) for an optional dependency. Regards -- Andy DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
Re: Minutes: JDO TCK Conference Call Thursday November 25 11 AM PST 20 CET
> 1. JDO 3.2 release RC4 > The release includes DataNucleus reference in the pom: core 5.2.7; > rdbms 5.2.7; api-jdo 5.2.7; jdo-query 5.0.9; api-jpa 5.2.6. > Are these the right DataNucleus versions for the 3.2 release? > We probably should remove the datanucleus api-jdo and instead use the > official 3.2 api. If you intend JDO 3.2 to be for JRE 1.8+ then you need the LATEST in the v5.x series datanucleus-core 5.2.9 datanucleus-api-jdo 5.2.7 datanucleus-api-jpa 5.2.8 datanucleus-rdbms 5.2.9 datanucleus-jdo-query 5.0.9 Removing datanucleus-api-jdo will make your life much harder since then you will be testing DataNucleus with NO SUPPORT for the JDO API. That is the DN API-support jar, not the API interfaces. Just like the associated datanucleus- api-jpa jar provides SUPPORT for the JPA API. Regards -- Andy DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
[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)
Re: [DISCUSS] Rename main branch?
> If we do rename I see the following steps: > - Rename master to main in both repositories gitbox and github. Most > probably this involves infra. > - Adapt some scripts and our documentation (WebSite, READMEs, ...) > - Change our workspaces as described in > https://issues.apache.org/jira/browse/JDO-793 If somebody decides to spend time on all of that just to avoid *potentially* upsetting some bed-wetter, based on no evidence that it could happen, then it simply says that this project has too much time on its hands and lack of focus in its priorities. To clarify, I'm not upset with the default branch name; don't know any sane person who is. Reminder : JDO 3.2 started in 2015. We're now in 2021. I'd rather like to have a *final* API jar at some point, and not have to rely on DataNucleus own variants. I'd have hoped this would be higher priority than namings ;-) Don't reply to this mail, it only wastes further time, and I certainly won't have a hissy fit whatever you decide to do. All the best Regards -- Andy DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
[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
[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
[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
[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) >
[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:
[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] - Exce
[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)
Re: Issue with enhancement of annotations
> I updated the pom.xml to 5.1.1-SNAPSHOT and the enhancer step worked but > many tck tests fail. [1] I'd suggest that is down to whatever is different in your TCK from the SVN trunk TCK ... because SVN trunk works fine with current DN code, and the only change in my fix is ignoring classes that are annotations, hence no persistable classes will be ignored due to this check. Regards -- Andy DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
Re: Issue with enhancement of annotations
Hi Craig,
> It looks like the DN enhancer recognizes the annotation as a
> persistence-capable class because it is annotated with PersistenceCapable
> but doesn't recognize it as an annotation that should not be enhanced.
Quite probably. I've only been enhancing through a persistence.xml file
recently, which explicitly specifies the classes to be enhanced so never hit
that one.
> I looked at the code and think that perhaps a patch like this would fix it.
> org.datanucleus.enhancer.ClassEnhancerImpl around line 298 after the cls
> object is obtained:
>
> if (cls.isAnnotation())
> {
> return false;
> }
>
> Other possible solutions: move the composite annotations out of the package
> into a sibling package. This probably works but is awkward.
No, let's just fix the code rather than imposing the user has to do something.
Instead of doing your proposed fix, I put a couple of checks in further
upstream, where it reads annotations for a class to check if it is has
metadata.
See https://github.com/datanucleus/datanucleus-core/commit/
f048a37494066b46545a1849d536104dc149950d
A simple test with that fix, explicitly adding the meta-annotation class to
persistence.xml results in a log message that the class has no metadata and is
ignored.
That should be in current DN nightly builds, so give it a try and see if it
catches your situation.
Regards
--
Andy
DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
[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(
[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)
Re: Minutes: JDO TCK Conference Call Friday October 28, 9 AM Pacific Daylight Time (PDT)
> 1. New JIRA JDO-757 "Add @Repeatable to all annotations which can be > repeated" https://issues.apache.org/jira/browse/JDO-757 > > Looks like we are almost done here. No need to deprecate existing “repeatable > container” annotations. If any user really wants to use them, fine. Well there would be zero point in deprecating them since they are required for @Repeatable to work, hence they can never be deleted. > Question: > why was ElementType.TYPE added to Column? What does this mean? Means that when @Column annotation was originally added it was incorrect. @Column on a class is to define "unmapped columns" to equate to just under in XML. When adding @Repeatable the compiler tells you about such errors so had to be fixed (so that the singular annotation with @Repeatable is consistent with the container annotation). Regards -- Andy DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
[jira] [Closed] (JDO-757) Add @Repeatable to all annotations which can be repeated
[
https://issues.apache.org/jira/browse/JDO-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Jefferson closed JDO-757.
--
Resolution: Fixed
test applied to SVN
> Add @Repeatable to all annotations which can be repeated
>
>
> Key: JDO-757
> URL: https://issues.apache.org/jira/browse/JDO-757
> Project: JDO
> Issue Type: Improvement
> Components: api
> Reporter: Andy Jefferson
> Assignee: Andy Jefferson
> Fix For: JDO 3.2
>
> Attachments: jdo-757-test.patch
>
>
> Since JDO 3.2 is for a minimum of Java 8, we can make annotations more usable
> by adding @Repeatable so that instead of
> @Extensions({@Extension(vendorName="datanucleus",key="option1",value="val"),@Extension(vendorName="datanucleus",key="option2",value="val")})
> the user can specify
> @Extension(vendorName="datanucleus", key="option1", value="val")
> @Extension(vendorName="datanucleus", key="option2", value="val")
> This should be done to all annotations that have an associated plural with
> "value" attribute
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [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)
Re: Minutes: JDO TCK Conference Call Friday October 7, 9 AM Pacific Daylight Time (PDT)
> In the first of Tilmanns examples he did "(...).isEmpty()", which you could
> get the equivalent of with "== null" I'd guess (without trying it).
Actually I doubt "== null" would suffice, but DataNucleus does support use of
EXISTS(subquery) internally for JPA support, so I just added basic support for
the special case of {subquery}.isEmpty() mapping across to "NOT EXISTS
(subquery)".
> In the second of Tilmanns examples he did "(...).get(num)" which you would
> have a lot of trouble translating to SQL, besides the fact that a Collection
> does not have a "get" method FWIW, only a List.
In fact the user can easily enough put a RANGE restriction on a query to get a
particular ROW, and change what is selected to return the precise object that
is needed, so there is no need for "get" to be supported.
If someone wants the equivalent of {subquery}.size() they should just make the
subquery a COUNT() subquery, which is already supported (since JDO 2.0)
Regards
--
Andy
DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
Re: Minutes: JDO TCK Conference Call Friday October 7, 9 AM Pacific Daylight Time (PDT)
> Tilmann reports that subqueries that return collections don’t seem to work. > The only subqueries that are tested in the tck return aggregates (AVG, MAX, > MIN, etc). > So should we change the specification to require that subqueries must return > single values? No, Tilmann actually reported that DataNucleus does not support INVOKING METHODS on the result of a subquery. Which is not the same as saying a subquery that returns non-aggregates "doesn't work". The JDO spec, when talking about methods, says "The following methods are supported for their specific types, with semantics as defined by the Java language:" That "specific type" is interpreted as the type of a FIELD/PROPERTY in DataNucleus. In terms of specifics:- In the first of Tilmanns examples he did "(...).isEmpty()", which you could get the equivalent of with "== null" I'd guess (without trying it). In the second of Tilmanns examples he did "(...).get(num)" which you would have a lot of trouble translating to SQL, besides the fact that a Collection does not have a "get" method FWIW, only a List. Anyway, if someone wants to implement support for invoking methods on SubqueryExpression they can get the code from the usual place. I've never seen a reasonable use-case for it (other than people saying I wonder what happens if I do this). Regards -- Andy DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
[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)
Re: navigation through single-valued relations and treatment of null references
> Can you give a specific example where INNER JOIN would give the wrong answer? There are likely many examples over the 8 years that this query generation mechanism has been in place; all defaults have been set based on what was needed to get a reliable mechanism for the vast majority of queries (and to cater for JDOQL and JPQL). I don't have time to go back through old history and work out some. What you can do is get the latest SNAPSHOT of "datanucleus-rdbms" and specify the persistence property "datanucleus.query.jdoql.navigationJoinTypeForFilter" as INNERJOIN (rather than the current default of working it out based on the NULLability of the field). This only applies to the FILTER of the query, so the SELECT clause will use the current default still. You can then run the TCK like that and see the effect. One I did see was a failure on org.apache.jdo.tck.query.jdoql.IfElseInFilter testPositive (which passes with current default join type strategy). This query has JDOQL of the form SELECT FROM org.apache.jdo.tck.pc.company.Employee WHERE (IF (this.manager == null) this.mentor.department.deptid ELSE this.manager.department.deptid) == this.department.deptid ORDER BY this.personid so likely the "IF THEN ELSE" expression in that example causing the difference. Anyone who wants to pursue this can look at the following classes The JDOQL query itself, look for method "compileQueryFull" https://github.com/datanucleus/datanucleus-rdbms/blob/master/src/main/java/org/datanucleus/store/rdbms/query/JDOQLQuery.java which then uses QueryToSQLMapper to convert the JDOQL compilation into an SQL query https://github.com/datanucleus/datanucleus-rdbms/blob/master/src/main/java/org/datanucleus/store/rdbms/query/QueryToSQLMapper.java And then kindly provide a Pull Request on GitHub that works for all situations. Regards -- Andy DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
Re: Minutes: JDO TCK Conference Call Friday July 29, 9 AM Pacific Daylight Time (PDT)
> 3. Experiments with queries and multiple navigations > > Looks like there is a bug in datanucleus when translating JDOQL to SQL by > using LEFT OUTER JOIN semantics when navigating a relationship. > > @Andy: is there a bug? Clearly, LEFT OUTER JOIN is needed when loading > objects with a fetch plan but when doing a query maybe the join should be a > straight inner join? As already stated on the issue about Optional, DataNucleus REQUIRES correct complete Java syntax for the JDOQL. That is, it requires the NULL check to be present in the JDOQL if navigating through relations, namely WHERE this.manager != null && this.manager.manager == null Regarding how to represent that as SQL, the problem is one of creating a dynamic query mechanism that caters for all queries (and you would be surprised at how elaborate people want to make their queries). If you have a WHERE clause with an OR (applying to the expression requiring the join) you to represent (1-1/N-1) relation navigation have to use LEFT OUTER JOIN since in SQL if you use INNER JOIN then that will apply to the other branch of the OR also, which would be wrong. Consequently with JDOQL the default join type is LEFT OUTER JOIN unless the relation has "optional=false" (when it becomes INNER JOIN). Clearly, if someone wanted to provide their time, the query creation mechanism could be made more complex and work out "oh there is a navigation through a relation but no OR therefore we'll use INNER JOIN", but I don't see people offering their time. Regarding DataNucleus supporting omission of the NULL check, again, that is down to resource. DataNucleus has a generic query compiler that simply converts the JDOQL into expression trees (before any SQL is even considered ... since the generic query compilation can be used for non-RDBMS datastores also). These expression trees could be analysed and the process could be extended to add in the NULL check expression when not provided. So someone could provide their time to do that, or you make it an optional feature for now until resource is available. Regards -- Andy DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
Re: JIRA 747
Hi Tilmann, > (sorry for double posting, I sent this to an...@apache.org before) I haven't used the Apache email for years since Apache gets loads of spam; I'd guess it goes to /dev/null on my ISP :-) > I started looking into adapting datanucleus for JDO JIRA 747: > https://issues.apache.org/jira/browse/JDO-747 > > Some time ago you offered to give some initial pointers, could you tell > me where to start? > > My first goal: Update datanuclues so that a PERSISTENT_NEW object > transitions to PERSISTENT_CLEAN when they are refreshed _and_ if there > is an object with the same ID in the database. The first place to look is the StateManager, which is in "datanucleus-core" at https://github.com/datanucleus/datanucleus-core/blob/master/src/main/java/org/datanucleus/state/StateManagerImpl.java The transition in Lifecycle states for JDO is controlled from "datanucleus-api-jdo", in this package https://github.com/datanucleus/datanucleus-api-jdo/tree/master/src/main/java/org/datanucleus/api/jdo/state I'd guess you need to look at class PersistentNew.java (the state the object is in) and look for a method transitionRefresh(), which looks like it uses the default implementation (do nothing) currently. FYI DataNucleus JPA has an equivalent set of Lifecycle states over in "datanucleus-api-jpa", so if changing anything in the lifecycle states for JDO (in datanucleus-api-jdo) then this will not affect DataNucleus JPA usage (a good thing). Beyond those, some other classes that you may need to be aware of are ExecutionContext (does the work of the PM), here https://github.com/datanucleus/datanucleus-core/blob/master/src/main/java/org/datanucleus/ExecutionContextImpl.java Transaction (for the ExecutionContext) https://github.com/datanucleus/datanucleus-core/blob/master/src/main/java/org/datanucleus/TransactionImpl.java Hope that helps -- Andy DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
[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)
Re: EmbeddedPCMapping cannot be cast to PersistableMapping
Hi,
> thanks. Indeed it seems that the error is triggered by declaring a field
> as 'Optional'.
That I doubt, due to established tests
https://github.com/datanucleus/tests/blob/master/jdo/general/src/test/org/datanucleus/tests/types/OptionalTest.java
More likely the problem is down to having a field as Optional, which is
a minority interest use-case IMHO (which can often be symptomatic of a problem
in a model, with lack of use of inheritance etc). Perhaps try nightly builds of
jars if having problems.
> Next step is likely to update the implementation.
DataNucleus has supported Optional since 5.0.0-m1, and tested on
Optional<{basic}>, Optional (see link). It hasn't been tested on
Optional where Object refers to potentially multiple types of PC.
Regards
--
Andy
DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
Re: A new general method to update object databases / Should it be included in Java Data Objects, JDO ?
Hi, > -I have invented a new declarative method to update object databases and I > would like to introduce that method you. > > My question is: > Should the functionality of this method included in some future versions of > JDO (and perhaps some other definitions/systems under Apache)? > Also I am interested about your comments/critique on the method. > > The name of the method is "embed" and it resembles the command > pm.makePersistent(s); > used in JDO-enabled applications. The embed method is called in equivalent > way, > db.embed(s); > but it has a larger functionality than the current makePersistent method. My opinion/comments, others may have other thoughts : For something to be part of JDO, it needs to be widely applicable across other datastores, not just for one "type" of datastore. If it is only implementable on 1 type of datastore then standardising it would be "premature"; that isn't to say that it isn't applicable to others. >From what I read of your method it is basically a makePersistent (attach) but >with "deleteOrphans" enabled; i.e it addresses the object graph defined by the >input object, and additionally deletes orphaned objects. Firstly it is >entirely reasonable to be able to do that right now in terms of API >(**assuming the JDO implementation provided the internals**) since the user >can call pm.makePersistent and can have set properties on the >PersistenceManager just before that call (pm.setProperty(...), so can set some >"deleteOrphans" flag). From that I can conclude that I don't think there would >be any change to the API needed to provide your mode of operation. Deleting orphans may vary dependent on the precise relation, hence why JDO allows metadata on each field, so some orphans can be deleted and others not. Clearly a JDO implementation would need to provide a "deleteOrphans" mode internally to support this. Detail of how your method works in an object database, whilst interesting, is not of relevance to the JDO spec question, since the spec doesn't define HOW an implementation implements features Regards -- Andy DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
Re: Minutes: JDO TCK Conference Call Friday April 15, 9 AM Pacific Daylight Time (PDT)
> 3. JDO-750 "Change development environment to JDK 1.8" > https://issues.apache.org/jira/browse/JDO-750 > > Not clear whether api or specification needs to call out specifically java 8. > The tck will now run only on java 8. You need the API to be built with Java8 since there are javax.jdo.query classes LocalDateExpression, LocalTimeExpression, LocalDateTimeExpression, OptionalExpression that support Java8 classes. Regards -- Andy DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
[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)
Re: Minutes: JDO TCK Conference Call Friday January 29, 9 AM Pacific Time (PST)
> 2. Spec updates JDO-749 "Support for java.time types, and querying using > associated methods" https://issues.apache.org/jira/browse/JDO-749 > > Chapter 14: why are other supported time types not orderable? No reason, I simply added LocalDateTime, LocalDate, LocalTime where Date was previously mentioned - this could become supported java.time types. But then there are other types not mentioned in that section that are supported as persistable (Locale, Calendar, etc), so why were they excluded?. Same applies in Result Class Requirements section. > Chapter 18: why don't other supported time types not have default JDBC types? Because the default still needs defining. To give an example java.time.YearMonth can be persisted (by DN) as * String * DATE (setting day to 0) * (INT, INT) storing the year and month. > There is special treatment for Local time, date, and date time. Are there > implementation issues? I see no implementation issue, and I also see no "special treatment" (in the spec). Where? > 4. Other issues > > There are several un-accepted changes in the specification noticed during > review of changes in JIRA issues. Do you mean "Track Changes" is ON in the spec docs in SVN? clearly, because the tracked changes in those docs are what has changed since 3.1 (so that it is easier to compile a list of changes when 3.2/4.0 is ever released). Or maybe you mean something else When is there confirmation of what this release is to be called? I'm assuming 3.2, but such a thing should be decided up front when the scope of changes is visible ... which it is. Regards -- Andy DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
[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)
