[jira] [Resolved] (OPENJPA-2917) Subclass enhancement might fail on long fields
[ https://issues.apache.org/jira/browse/OPENJPA-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-2917. Resolution: Fixed > Subclass enhancement might fail on long fields > -- > > Key: OPENJPA-2917 > URL: https://issues.apache.org/jira/browse/OPENJPA-2917 > Project: OpenJPA > Issue Type: Improvement > Components: Enhance >Affects Versions: 4.0.0 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 4.0.0 > > > When using subclass enhancement we fail on certain long field scenarios as we > had a fixed offset stack calculation instead of taking into account that long > uses 2 bytes on the stack. This just affects the new ASM based enhancement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OPENJPA-2917) Subclass enhancement might fail on long fields
Mark Struberg created OPENJPA-2917: -- Summary: Subclass enhancement might fail on long fields Key: OPENJPA-2917 URL: https://issues.apache.org/jira/browse/OPENJPA-2917 Project: OpenJPA Issue Type: Improvement Components: Enhance Affects Versions: 4.0.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 4.0.0 When using subclass enhancement we fail on certain long field scenarios as we had a fixed offset stack calculation instead of taking into account that long uses 2 bytes on the stack. This just affects the new ASM based enhancement. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (OPENJPA-2915) commons-dbcp2 2.10.0 breaks OpenJPA because of changed configuration methods
[
https://issues.apache.org/jira/browse/OPENJPA-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg reassigned OPENJPA-2915:
--
Assignee: Mark Struberg
> commons-dbcp2 2.10.0 breaks OpenJPA because of changed configuration methods
>
>
> Key: OPENJPA-2915
> URL: https://issues.apache.org/jira/browse/OPENJPA-2915
> Project: OpenJPA
> Issue Type: Bug
> Components: third-party
>Affects Versions: 3.2.2
>Reporter: Dominik Stadler
>Assignee: Mark Struberg
>Priority: Minor
>
> When upgrading commons-dbcp2 to the latest version 2.10.0, OpenJPA fails with
> exceptions when it tries to provide options to commons-dbcp2.
> It seems this happens because dbcp2 moved from Integer-Duration to using
> java.time.Duration.
> See
> [https://github.com/apache/commons-dbcp/commit/93207813fd6b6c0230cfcebb0e9f5b19e9fa72b9]
> It seems that even though the change in dbcp2 was done in a
> backwards-compatible way, the automatic configuration handling in OpenJPA
> stumbles and throws an exception when latest commons-dbcp2 (and
> commons-pool2) are used:
> {noformat}
> Caused by: org.apache.openjpa.lib.util.ParseException:
> org.apache.commons.dbcp2.BasicDataSource@72eed4db.MaxWait = 1
> at app//org.apache.openjpa.lib.util.Options.setInto(Options.java:234)
> at app//org.apache.openjpa.lib.util.Options.setInto(Options.java:187)
> at
> app//org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:502)
> at
> app//org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:456)
> at
> app//org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:436)
> at
> app//org.apache.openjpa.lib.conf.Configurations.newInstance(Configurations.java:169)
> at
> app//org.apache.openjpa.jdbc.schema.DataSourceFactory.newDataSource(DataSourceFactory.java:112)
> ... 63 more
> Caused by: org.apache.openjpa.lib.util.ParseException: Error initializing
> configuration. Failed to create an instance of class java.time.Duration for
> plugin property 1.
> at
> app//org.apache.openjpa.lib.util.Options.stringToObject(Options.java:449)
> at app//org.apache.openjpa.lib.util.Options.setInto(Options.java:226)
> ... 69 more
> Caused by: java.lang.ClassNotFoundException: 1
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:527)
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:315)
> at org.apache.openjpa.lib.util.Options.stringToObject(Options.java:446)
> ... 70 more
> {noformat}
>
> It should be possible to reproduce with a small OpenJPA sample project and
> adding the following two newer Gradle dependencies:
> {noformat}
> implementation 'org.apache.commons:commons-dbcp2:2.9.0'
> implementation 'org.apache.commons:commons-pool2:2.11.1'{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OPENJPA-2914) upgrade xbean to 4.23
[ https://issues.apache.org/jira/browse/OPENJPA-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-2914. Resolution: Fixed > upgrade xbean to 4.23 > - > > Key: OPENJPA-2914 > URL: https://issues.apache.org/jira/browse/OPENJPA-2914 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Affects Versions: 3.2.2 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 4.0.0 > > > upgrade xbean from 4.22 to 4.23 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OPENJPA-2914) upgrade xbean to 4.23
Mark Struberg created OPENJPA-2914: -- Summary: upgrade xbean to 4.23 Key: OPENJPA-2914 URL: https://issues.apache.org/jira/browse/OPENJPA-2914 Project: OpenJPA Issue Type: Improvement Components: kernel Affects Versions: 3.2.2 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 4.0.0 upgrade xbean from 4.22 to 4.23 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OPENJPA-2911) Replace Serp with native ASM code
[ https://issues.apache.org/jira/browse/OPENJPA-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-2911. Resolution: Fixed We finally got rid of Serp and moved all the parts to Geronimo xbean-asm. > Replace Serp with native ASM code > - > > Key: OPENJPA-2911 > URL: https://issues.apache.org/jira/browse/OPENJPA-2911 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Affects Versions: 4.0.0 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 4.0.0 > > > We have a lot of Code leveraging Serp to create Java bytecode. But Serp is > unmaintained and is only able to create Java5 bytecode. Thus we shall replace > it with ASM. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OPENJPA-2912) Support jdk.attach.jmod in InstrumentationFactory
Mark Struberg created OPENJPA-2912: -- Summary: Support jdk.attach.jmod in InstrumentationFactory Key: OPENJPA-2912 URL: https://issues.apache.org/jira/browse/OPENJPA-2912 Project: OpenJPA Issue Type: Improvement Reporter: Mark Struberg Assignee: Mark Struberg Right now our code still relies on tools.jar. If it is not available we currently turn off class redefinition. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OPENJPA-2911) Replace Serp with native ASM code
Mark Struberg created OPENJPA-2911: -- Summary: Replace Serp with native ASM code Key: OPENJPA-2911 URL: https://issues.apache.org/jira/browse/OPENJPA-2911 Project: OpenJPA Issue Type: Improvement Components: kernel Affects Versions: 4.0.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 4.0.0 We have a lot of Code leveraging Serp to create Java bytecode. But Serp is unmaintained and is only able to create Java5 bytecode. Thus we shall replace it with ASM. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OPENJPA-2909) implement field proxies with ASM instead Serp
[ https://issues.apache.org/jira/browse/OPENJPA-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-2909. Resolution: Fixed > implement field proxies with ASM instead Serp > - > > Key: OPENJPA-2909 > URL: https://issues.apache.org/jira/browse/OPENJPA-2909 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Affects Versions: 4.0.0 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 4.0.0 > > > Right now we use Serp for creating our field proxies. Serp only creates Java5 > Bytecode and is largely unmaintained. So we should move to ASM. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OPENJPA-2910) implement WASManagedRuntime witout Serp
[ https://issues.apache.org/jira/browse/OPENJPA-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-2910. Resolution: Fixed > implement WASManagedRuntime witout Serp > --- > > Key: OPENJPA-2910 > URL: https://issues.apache.org/jira/browse/OPENJPA-2910 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Affects Versions: 4.0.0 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 4.0.0 > > > Get rid of Serp in WASManagedRuntime. Since those com.ibm classes are now > publicly available from io.openliberty we can use those. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OPENJPA-2910) implement WASManagedRuntime witout Serp
Mark Struberg created OPENJPA-2910: -- Summary: implement WASManagedRuntime witout Serp Key: OPENJPA-2910 URL: https://issues.apache.org/jira/browse/OPENJPA-2910 Project: OpenJPA Issue Type: Improvement Components: kernel Affects Versions: 4.0.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 4.0.0 Get rid of Serp in WASManagedRuntime. Since those com.ibm classes are now publicly available from io.openliberty we can use those. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OPENJPA-2909) implement field proxies with ASM instead Serp
Mark Struberg created OPENJPA-2909: -- Summary: implement field proxies with ASM instead Serp Key: OPENJPA-2909 URL: https://issues.apache.org/jira/browse/OPENJPA-2909 Project: OpenJPA Issue Type: Improvement Components: kernel Affects Versions: 4.0.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 4.0.0 Right now we use Serp for creating our field proxies. Serp only creates Java5 Bytecode and is largely unmaintained. So we should move to ASM. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OPENJPA-2908) implement Jakarta JPA 3.1
Mark Struberg created OPENJPA-2908: -- Summary: implement Jakarta JPA 3.1 Key: OPENJPA-2908 URL: https://issues.apache.org/jira/browse/OPENJPA-2908 Project: OpenJPA Issue Type: Improvement Affects Versions: 4.0.0 Reporter: Mark Struberg Fix For: 4.0.0 This is a summary task to implement Jakarta JPA 3.1 (Jakarta EE 10). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OPENJPA-2614) First rollback after application start does not work under certain circumstances
[ https://issues.apache.org/jira/browse/OPENJPA-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-2614. Fix Version/s: 3.2.1 Assignee: Mark Struberg Resolution: Fixed We now do open a new Connection for those operations. > First rollback after application start does not work under certain > circumstances > > > Key: OPENJPA-2614 > URL: https://issues.apache.org/jira/browse/OPENJPA-2614 > Project: OpenJPA > Issue Type: Bug > Components: jpa >Affects Versions: 2.4.0 >Reporter: Tim Gödde >Assignee: Mark Struberg >Priority: Major > Fix For: 3.2.1 > > Attachments: jpa-test.zip > > > Rollback is not complete under the following circumstances: > 1. Entites must use a sequence generator with GenerationType.SEQUENCE > 2. It is the first rollback after application start > 3. You have to flush successfully during the creation of entities > 4. The transaction is rolled back during commit because of a constraint > violation > Expected result: Nothing remains in the database that is created during the > transaction > Actual result: Entites created before the flush are persisted (i.e. not > rolled back) > An example project is attached. It shows the described problem when executing > the test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2869) Specification-Version still in v2
[ https://issues.apache.org/jira/browse/OPENJPA-2869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-2869. Fix Version/s: 3.2.0 Assignee: Mark Struberg Resolution: Fixed fixed that in 3.2.0 already > Specification-Version still in v2 > - > > Key: OPENJPA-2869 > URL: https://issues.apache.org/jira/browse/OPENJPA-2869 > Project: OpenJPA > Issue Type: Task >Affects Versions: 3.1.2 >Reporter: Romain Manni-Bucau >Assignee: Mark Struberg >Priority: Major > Fix For: 3.2.0 > > > 2.0 is still used in our poms -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (OPENJPA-2869) Specification-Version still in v2
[ https://issues.apache.org/jira/browse/OPENJPA-2869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed OPENJPA-2869. -- > Specification-Version still in v2 > - > > Key: OPENJPA-2869 > URL: https://issues.apache.org/jira/browse/OPENJPA-2869 > Project: OpenJPA > Issue Type: Task >Affects Versions: 3.1.2 >Reporter: Romain Manni-Bucau >Assignee: Mark Struberg >Priority: Major > Fix For: 3.2.0 > > > 2.0 is still used in our poms -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2876) running 'refresh' schema action creates wrong SQL output
[
https://issues.apache.org/jira/browse/OPENJPA-2876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved OPENJPA-2876.
Resolution: Fixed
> running 'refresh' schema action creates wrong SQL output
>
>
> Key: OPENJPA-2876
> URL: https://issues.apache.org/jira/browse/OPENJPA-2876
> Project: OpenJPA
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.2.1
>
>
> Seems we trashed the SQL refresh feature along the way to JPA-2.0.
> I have a sample with an Entity 'Customer' with just an ID. Then I add a
> column {{OTHER_NAME}} and generate the result with {{sqlAction=refresh}}
> In OpenJPA-2.4.3 we get the following output:
> {noformat}
> ALTER TABLE CUSTOMER ADD COLUMN OTHER_NAME VARCHAR(255);
> {noformat}
> In OpenJPA-3.0.0 onwards we get this:
> {noformat}
> ALTER TABLE CUSTOMER ADD COLUMN OTHER_NAME VARCHAR(255);
> CREATE TABLE CUSTOMER (ID BIGINT NOT NULL, active VARCHAR(1), OTHER_NAME
> VARCHAR(255), specialCustomer VARCHAR(1) NOT NULL, PRIMARY KEY (ID));
> CREATE TABLE OPENJPA_SEQUENCE_TABLE (ID TINYINT NOT NULL, SEQUENCE_VALUE
> BIGINT, PRIMARY KEY (ID));
> CREATE TABLE PUBLIC.CUSTOMER (ID BIGINT, ACTIVE VARCHAR(1), NAME
> VARCHAR(255), SPECIALCUSTOMER VARCHAR(1));
> {noformat}
> It seems like we do not only run the MappingAction 'refresh' but also a
> 'build' plus we do it also without Schema and with the current Schema
> (PUBLIC).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OPENJPA-2876) running 'refresh' schema action creates wrong SQL output
[
https://issues.apache.org/jira/browse/OPENJPA-2876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361204#comment-17361204
]
Mark Struberg commented on OPENJPA-2876:
git-bisect tells us it was commit af8ea38f87a778401ca1c679f7087d3a0d5a52cc
OPENJPA-2554 JPA 2.1 - Schema Generation
> running 'refresh' schema action creates wrong SQL output
>
>
> Key: OPENJPA-2876
> URL: https://issues.apache.org/jira/browse/OPENJPA-2876
> Project: OpenJPA
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.2.1
>
>
> Seems we trashed the SQL refresh feature along the way to JPA-2.0.
> I have a sample with an Entity 'Customer' with just an ID. Then I add a
> column {{OTHER_NAME}} and generate the result with {{sqlAction=refresh}}
> In OpenJPA-2.4.3 we get the following output:
> {noformat}
> ALTER TABLE CUSTOMER ADD COLUMN OTHER_NAME VARCHAR(255);
> {noformat}
> In OpenJPA-3.0.0 onwards we get this:
> {noformat}
> ALTER TABLE CUSTOMER ADD COLUMN OTHER_NAME VARCHAR(255);
> CREATE TABLE CUSTOMER (ID BIGINT NOT NULL, active VARCHAR(1), OTHER_NAME
> VARCHAR(255), specialCustomer VARCHAR(1) NOT NULL, PRIMARY KEY (ID));
> CREATE TABLE OPENJPA_SEQUENCE_TABLE (ID TINYINT NOT NULL, SEQUENCE_VALUE
> BIGINT, PRIMARY KEY (ID));
> CREATE TABLE PUBLIC.CUSTOMER (ID BIGINT, ACTIVE VARCHAR(1), NAME
> VARCHAR(255), SPECIALCUSTOMER VARCHAR(1));
> {noformat}
> It seems like we do not only run the MappingAction 'refresh' but also a
> 'build' plus we do it also without Schema and with the current Schema
> (PUBLIC).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OPENJPA-2876) running 'refresh' schema action creates wrong SQL output
Mark Struberg created OPENJPA-2876:
--
Summary: running 'refresh' schema action creates wrong SQL output
Key: OPENJPA-2876
URL: https://issues.apache.org/jira/browse/OPENJPA-2876
Project: OpenJPA
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 3.2.1
Seems we trashed the SQL refresh feature along the way to JPA-2.0.
I have a sample with an Entity 'Customer' with just an ID. Then I add a column
{{OTHER_NAME}} and generate the result with {{sqlAction=refresh}}
In OpenJPA-2.4.3 we get the following output:
{noformat}
ALTER TABLE CUSTOMER ADD COLUMN OTHER_NAME VARCHAR(255);
{noformat}
In OpenJPA-3.0.0 onwards we get this:
{noformat}
ALTER TABLE CUSTOMER ADD COLUMN OTHER_NAME VARCHAR(255);
CREATE TABLE CUSTOMER (ID BIGINT NOT NULL, active VARCHAR(1), OTHER_NAME
VARCHAR(255), specialCustomer VARCHAR(1) NOT NULL, PRIMARY KEY (ID));
CREATE TABLE OPENJPA_SEQUENCE_TABLE (ID TINYINT NOT NULL, SEQUENCE_VALUE
BIGINT, PRIMARY KEY (ID));
CREATE TABLE PUBLIC.CUSTOMER (ID BIGINT, ACTIVE VARCHAR(1), NAME VARCHAR(255),
SPECIALCUSTOMER VARCHAR(1));
{noformat}
It seems like we do not only run the MappingAction 'refresh' but also a 'build'
plus we do it also without Schema and with the current Schema (PUBLIC).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2873) Add ProductDerivation for persistence_2_2.xsd
[ https://issues.apache.org/jira/browse/OPENJPA-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-2873. Resolution: Fixed > Add ProductDerivation for persistence_2_2.xsd > - > > Key: OPENJPA-2873 > URL: https://issues.apache.org/jira/browse/OPENJPA-2873 > Project: OpenJPA > Issue Type: New Feature > Components: jpa >Reporter: Mark Struberg >Priority: Major > Fix For: 3.2.0 > > > Add ProductDerivation for persistence_2_2.xsd. Right now we only support > persistence.xml versions 1.0, 2.0 and 2.1. > There is no schema change though, it's just version update. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2765) Fix documentation of JPA spec compliance
[ https://issues.apache.org/jira/browse/OPENJPA-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-2765. Resolution: Fixed > Fix documentation of JPA spec compliance > > > Key: OPENJPA-2765 > URL: https://issues.apache.org/jira/browse/OPENJPA-2765 > Project: OpenJPA > Issue Type: Improvement >Reporter: Oliver Drotbohm >Assignee: Mark Struberg >Priority: Major > Fix For: 3.2.0 > > > Depending on where you look, there's currently contradicting information > about the JPA specification version compliance of OpenJPA. > - The [project homepage|http://openjpa.apache.org/] states 3.0 "targets" JPA > 2.1. > - The [3.0 > announcement|http://openjpa.apache.org/openjpa-3.0.x.html#OpenJPA-3.0.0] > states 3.0 is "based on" JPA 2.2. > - The [About section of the reference > documentation|http://openjpa.apache.org/builds/3.0.0/apache-openjpa/docs/manual.html#openjpa_intro] > states that 3.0 implements JPA 2.0. > It would be cool if this could be clarified. I assume the latter is just an > oversight and a missing update. However it would also be cool if for the > former two, it could be clarified what being "based on" and "targetting" > actually means. > A [Twitter > conversation|https://twitter.com/odrotbohm/status/1081713555290972160] seems > to reveal that 3.0 *implements* 2.1 and has partial support for 2.2 features. > Would be cool if that could be confirmed and documented accordingly, esp. > which of the 2.2 features are supposed to work. > So to me it looks like follows: > - 2.x – implements JPA 2.0 > - 3.0 – implements JPA 2.1, partial support for 2.2 > The [Wikipedia page on > JPA|https://en.wikipedia.org/wiki/Java_Persistence_API] could use an update > on this as well. I can help with that, if you come to a decision what to > phrase the current state of affairs. > Thanks and keep up the great work! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OPENJPA-2873) Add ProductDerivation for persistence_2_2.xsd
[ https://issues.apache.org/jira/browse/OPENJPA-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated OPENJPA-2873: --- Description: Add ProductDerivation for persistence_2_2.xsd. Right now we only support persistence.xml versions 1.0, 2.0 and 2.1. There is no schema change though, it's just version update. > Add ProductDerivation for persistence_2_2.xsd > - > > Key: OPENJPA-2873 > URL: https://issues.apache.org/jira/browse/OPENJPA-2873 > Project: OpenJPA > Issue Type: New Feature > Components: jpa >Reporter: Mark Struberg >Priority: Major > Fix For: 3.2.0 > > > Add ProductDerivation for persistence_2_2.xsd. Right now we only support > persistence.xml versions 1.0, 2.0 and 2.1. > There is no schema change though, it's just version update. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2873) Add ProductDerivation for persistence_2_2.xsd
Mark Struberg created OPENJPA-2873: -- Summary: Add ProductDerivation for persistence_2_2.xsd Key: OPENJPA-2873 URL: https://issues.apache.org/jira/browse/OPENJPA-2873 Project: OpenJPA Issue Type: New Feature Components: jpa Affects Versions: 3.1.2 Reporter: Mark Struberg -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OPENJPA-2873) Add ProductDerivation for persistence_2_2.xsd
[ https://issues.apache.org/jira/browse/OPENJPA-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated OPENJPA-2873: --- Fix Version/s: 3.2.0 > Add ProductDerivation for persistence_2_2.xsd > - > > Key: OPENJPA-2873 > URL: https://issues.apache.org/jira/browse/OPENJPA-2873 > Project: OpenJPA > Issue Type: New Feature > Components: jpa >Reporter: Mark Struberg >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OPENJPA-2873) Add ProductDerivation for persistence_2_2.xsd
[ https://issues.apache.org/jira/browse/OPENJPA-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated OPENJPA-2873: --- Affects Version/s: (was: 3.1.2) > Add ProductDerivation for persistence_2_2.xsd > - > > Key: OPENJPA-2873 > URL: https://issues.apache.org/jira/browse/OPENJPA-2873 > Project: OpenJPA > Issue Type: New Feature > Components: jpa >Reporter: Mark Struberg >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2872) provide Jakarta EE artifacts
[ https://issues.apache.org/jira/browse/OPENJPA-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-2872. Fix Version/s: (was: 3.2.0) 3.1.2 Resolution: Duplicate oh, indeed, txs! So we are almost set to roll a release! > provide Jakarta EE artifacts > > > Key: OPENJPA-2872 > URL: https://issues.apache.org/jira/browse/OPENJPA-2872 > Project: OpenJPA > Issue Type: New Feature > Components: build / infrastructure >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 3.1.2 > > > With 3.2.0 we should also add JakartaEE artifacts. We can simply add a > shading to provide those via an attached artifact with classifier 'jakarta'. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2872) provide Jakarta EE artifacts
Mark Struberg created OPENJPA-2872: -- Summary: provide Jakarta EE artifacts Key: OPENJPA-2872 URL: https://issues.apache.org/jira/browse/OPENJPA-2872 Project: OpenJPA Issue Type: New Feature Components: build / infrastructure Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 3.2.0 With 3.2.0 we should also add JakartaEE artifacts. We can simply add a shading to provide those via an attached artifact with classifier 'jakarta'. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OPENJPA-2765) Fix documentation of JPA spec compliance
[ https://issues.apache.org/jira/browse/OPENJPA-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned OPENJPA-2765: -- Assignee: Mark Struberg > Fix documentation of JPA spec compliance > > > Key: OPENJPA-2765 > URL: https://issues.apache.org/jira/browse/OPENJPA-2765 > Project: OpenJPA > Issue Type: Improvement >Reporter: Oliver Drotbohm >Assignee: Mark Struberg >Priority: Major > > Depending on where you look, there's currently contradicting information > about the JPA specification version compliance of OpenJPA. > - The [project homepage|http://openjpa.apache.org/] states 3.0 "targets" JPA > 2.1. > - The [3.0 > announcement|http://openjpa.apache.org/openjpa-3.0.x.html#OpenJPA-3.0.0] > states 3.0 is "based on" JPA 2.2. > - The [About section of the reference > documentation|http://openjpa.apache.org/builds/3.0.0/apache-openjpa/docs/manual.html#openjpa_intro] > states that 3.0 implements JPA 2.0. > It would be cool if this could be clarified. I assume the latter is just an > oversight and a missing update. However it would also be cool if for the > former two, it could be clarified what being "based on" and "targetting" > actually means. > A [Twitter > conversation|https://twitter.com/odrotbohm/status/1081713555290972160] seems > to reveal that 3.0 *implements* 2.1 and has partial support for 2.2 features. > Would be cool if that could be confirmed and documented accordingly, esp. > which of the 2.2 features are supposed to work. > So to me it looks like follows: > - 2.x – implements JPA 2.0 > - 3.0 – implements JPA 2.1, partial support for 2.2 > The [Wikipedia page on > JPA|https://en.wikipedia.org/wiki/Java_Persistence_API] could use an update > on this as well. I can help with that, if you come to a decision what to > phrase the current state of affairs. > Thanks and keep up the great work! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OPENJPA-2765) Fix documentation of JPA spec compliance
[ https://issues.apache.org/jira/browse/OPENJPA-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated OPENJPA-2765: --- Fix Version/s: 3.2.0 > Fix documentation of JPA spec compliance > > > Key: OPENJPA-2765 > URL: https://issues.apache.org/jira/browse/OPENJPA-2765 > Project: OpenJPA > Issue Type: Improvement >Reporter: Oliver Drotbohm >Assignee: Mark Struberg >Priority: Major > Fix For: 3.2.0 > > > Depending on where you look, there's currently contradicting information > about the JPA specification version compliance of OpenJPA. > - The [project homepage|http://openjpa.apache.org/] states 3.0 "targets" JPA > 2.1. > - The [3.0 > announcement|http://openjpa.apache.org/openjpa-3.0.x.html#OpenJPA-3.0.0] > states 3.0 is "based on" JPA 2.2. > - The [About section of the reference > documentation|http://openjpa.apache.org/builds/3.0.0/apache-openjpa/docs/manual.html#openjpa_intro] > states that 3.0 implements JPA 2.0. > It would be cool if this could be clarified. I assume the latter is just an > oversight and a missing update. However it would also be cool if for the > former two, it could be clarified what being "based on" and "targetting" > actually means. > A [Twitter > conversation|https://twitter.com/odrotbohm/status/1081713555290972160] seems > to reveal that 3.0 *implements* 2.1 and has partial support for 2.2 features. > Would be cool if that could be confirmed and documented accordingly, esp. > which of the 2.2 features are supposed to work. > So to me it looks like follows: > - 2.x – implements JPA 2.0 > - 3.0 – implements JPA 2.1, partial support for 2.2 > The [Wikipedia page on > JPA|https://en.wikipedia.org/wiki/Java_Persistence_API] could use an update > on this as well. I can help with that, if you come to a decision what to > phrase the current state of affairs. > Thanks and keep up the great work! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2868) update reserved column names list for various of our DBDictionaries
[ https://issues.apache.org/jira/browse/OPENJPA-2868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-2868. Resolution: Fixed > update reserved column names list for various of our DBDictionaries > --- > > Key: OPENJPA-2868 > URL: https://issues.apache.org/jira/browse/OPENJPA-2868 > Project: OpenJPA > Issue Type: Improvement > Components: jdbc >Affects Versions: 3.1.2 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 3.2.0 > > > Quite a few of our Dictionaries have the reserved keyword list not up2date. > With OPENJPA-2867 we are now able to update those to what really works. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OPENJPA-2837) HerdDBDictionary does not work with 'native' SchemaFactory (LazySchemaFactory) - set useSchemaName=false by default
[
https://issues.apache.org/jira/browse/OPENJPA-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg updated OPENJPA-2837:
---
Fix Version/s: (was: 3.2.0)
3.2.1
> HerdDBDictionary does not work with 'native' SchemaFactory
> (LazySchemaFactory) - set useSchemaName=false by default
> ---
>
> Key: OPENJPA-2837
> URL: https://issues.apache.org/jira/browse/OPENJPA-2837
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 3.1.2
>Reporter: Enrico Olivelli
>Priority: Critical
> Fix For: 3.2.1
>
>
> If you want to enable physical Foreign Keys you have to configure
> SchemaFactory with 'native'.
> In this case the LazySchemaFactory does not handle correctly delimiters and
> everything breaks, even the creation of OPENJPA_SEQUENCE table.
>
> The problem is that the query generated for loading the sequence value is:
> {code:java}
> SELECT `SEQUENCE_VALUE` FROM "herd"."`OPENJPA_SEQUENCE_TABLE`" WHERE `ID` = ?
> FOR UPDATE [params=?]{code}
>
> It is adding default delimiters to the schema name and the tablename.
> the problem is in TableJDBCSeq.java, using LazySchemaFactory the primary
> table name is augmented with the schema name ("herd" in this case) and this
> triggers the 4th case in "resolveTableIdentifier"
>
>
> {code:java}
> public DBIdentifier resolveTableIdentifier(ClassMapping mapping, Table table)
> {
> DBIdentifier sName = mapping.getTable().getSchemaIdentifier();
> DBIdentifier tableName = DBIdentifier.NULL;
> //OPENJPA-2650: Don't use a schema name if the user has requested,
> //via useSchemaName, to not use one.
> if (!_conf.getDBDictionaryInstance().useSchemaName){
> tableName = table.getIdentifier();
> } else if (DBIdentifier.isNull(sName)) {
> tableName = table.getFullIdentifier();
> } else if (!DBIdentifier.isNull(table.getSchemaIdentifier())) {
> tableName = table.getFullIdentifier();
> } else {
> tableName = QualifiedDBIdentifier.newPath(sName, table.getIdentifier());
> }
> return tableName;
> }
> {code}
>
>
> This tracks down to QualifiedDBIdentifier.newPath(sName,
> table.getIdentifier()); that basically does not work when you have compound
> identifiers and delimiters.
> When you are using DynamicSchemaFactory the problem does not arise because we
> fall into case 2h (QualifiedDBIdentifier.newPath(sName,
> table.getIdentifier()) ) and we are not passing by
> QualifiedDBIdentifier.newPath.
>
> The problem is NOT only in QualifiedDBIdentifier.newPath. but it becomes a
> problem when you perform SQLBuffer#append, that in turn calls
> DBDictionary#fromDBName, that tries to add dict specific delimiters (in this
> case with HerdDBDirection the backtick)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2871) upgrade to xbean-4.20 to remove transitive ASM dependency
[ https://issues.apache.org/jira/browse/OPENJPA-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-2871. Resolution: Fixed > upgrade to xbean-4.20 to remove transitive ASM dependency > - > > Key: OPENJPA-2871 > URL: https://issues.apache.org/jira/browse/OPENJPA-2871 > Project: OpenJPA > Issue Type: Bug > Components: build / infrastructure >Affects Versions: 3.2.0 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 3.2.0 > > > xBean-4.18 and 4.19 do leak ASM dependencies. That's fixed in xbean-4.20. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2871) upgrade to xbean-4.20 to remove transitive ASM dependency
Mark Struberg created OPENJPA-2871: -- Summary: upgrade to xbean-4.20 to remove transitive ASM dependency Key: OPENJPA-2871 URL: https://issues.apache.org/jira/browse/OPENJPA-2871 Project: OpenJPA Issue Type: Bug Components: build / infrastructure Affects Versions: 3.2.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 3.2.0 xBean-4.18 and 4.19 do leak ASM dependencies. That's fixed in xbean-4.20. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2870) update specification-version to 2.2
[ https://issues.apache.org/jira/browse/OPENJPA-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-2870. Resolution: Fixed > update specification-version to 2.2 > --- > > Key: OPENJPA-2870 > URL: https://issues.apache.org/jira/browse/OPENJPA-2870 > Project: OpenJPA > Issue Type: Improvement > Components: build / infrastructure >Affects Versions: 3.1.2 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 3.2.0 > > > update specification-version to 2.2 > We still use 2.0 till now. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2870) update specification-version to 2.2
Mark Struberg created OPENJPA-2870: -- Summary: update specification-version to 2.2 Key: OPENJPA-2870 URL: https://issues.apache.org/jira/browse/OPENJPA-2870 Project: OpenJPA Issue Type: Improvement Components: build / infrastructure Affects Versions: 3.1.2 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 3.2.0 update specification-version to 2.2 We still use 2.0 till now. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2867) generate list of reserved Words via unit test
[ https://issues.apache.org/jira/browse/OPENJPA-2867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-2867. Resolution: Fixed > generate list of reserved Words via unit test > - > > Key: OPENJPA-2867 > URL: https://issues.apache.org/jira/browse/OPENJPA-2867 > Project: OpenJPA > Issue Type: Improvement > Components: jdbc >Affects Versions: 3.1.2 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 3.2.0 > > > There are about 1000 reserved keywords known in the SQL universe. But not > everyone is a reserved word for every database. > Thus we should create a unit test which tries out creating tables with those > keywords. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2868) update reserved column names list for various of our DBDictionaries
Mark Struberg created OPENJPA-2868: -- Summary: update reserved column names list for various of our DBDictionaries Key: OPENJPA-2868 URL: https://issues.apache.org/jira/browse/OPENJPA-2868 Project: OpenJPA Issue Type: Improvement Components: jdbc Affects Versions: 3.1.2 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 3.2.0 Quite a few of our Dictionaries have the reserved keyword list not up2date. With OPENJPA-2867 we are now able to update those to what really works. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2867) generate list of reserved Words via unit test
Mark Struberg created OPENJPA-2867: -- Summary: generate list of reserved Words via unit test Key: OPENJPA-2867 URL: https://issues.apache.org/jira/browse/OPENJPA-2867 Project: OpenJPA Issue Type: Improvement Components: jdbc Affects Versions: 3.1.2 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 3.2.0 There are about 1000 reserved keywords known in the SQL universe. But not everyone is a reserved word for every database. Thus we should create a unit test which tries out creating tables with those keywords. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OPENJPA-2808) SchemaTool action DROP doesn't drop Indexes created with @Index
[
https://issues.apache.org/jira/browse/OPENJPA-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17330072#comment-17330072
]
Mark Struberg commented on OPENJPA-2808:
Is it ok to move this to 3.2.1? We need to take a deeper look at it. Might be
depending on the database, etc.
> SchemaTool action DROP doesn't drop Indexes created with @Index
> ---
>
> Key: OPENJPA-2808
> URL: https://issues.apache.org/jira/browse/OPENJPA-2808
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
>Affects Versions: 3.1.1
>Reporter: Mark Struberg
>Assignee: Maxim Solodovnik
>Priority: Major
> Fix For: 3.1.3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When using {{@Index(name="IFK_SOMEFK",...}} we should also drop this when
> generating the DROP statement with our SchemaTool.
> e.g. when setting
> {noformat}
>
> org.apache.openjpa
> openjpa-maven-plugin
> ${openjpa.version}
>
> drop
>
>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OPENJPA-2808) SchemaTool action DROP doesn't drop Indexes created with @Index
[
https://issues.apache.org/jira/browse/OPENJPA-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17329451#comment-17329451
]
Mark Struberg commented on OPENJPA-2808:
Hi [~solomax] !
While creating a unit test for this scenario I figured that we likely do not
want to create an explicit {{DROP INDEX}}. Usually an Index is bound to a
table. This is explicitly the case for {{@Index}} in the {{@Table}} annotation.
And when you drop the table, the index will also automatically get discarded.
Which means we do not need to take care about those Indexes, isn't?
> SchemaTool action DROP doesn't drop Indexes created with @Index
> ---
>
> Key: OPENJPA-2808
> URL: https://issues.apache.org/jira/browse/OPENJPA-2808
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
>Affects Versions: 3.1.1
>Reporter: Mark Struberg
>Assignee: Maxim Solodovnik
>Priority: Major
> Fix For: 3.1.3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When using {{@Index(name="IFK_SOMEFK",...}} we should also drop this when
> generating the DROP statement with our SchemaTool.
> e.g. when setting
> {noformat}
>
> org.apache.openjpa
> openjpa-maven-plugin
> ${openjpa.version}
>
> drop
>
>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (OPENJPA-2841) Broken superfluous joins with subqueries
[
https://issues.apache.org/jira/browse/OPENJPA-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg reassigned OPENJPA-2841:
--
Assignee: Mark Struberg
> Broken superfluous joins with subqueries
>
>
> Key: OPENJPA-2841
> URL: https://issues.apache.org/jira/browse/OPENJPA-2841
> Project: OpenJPA
> Issue Type: Bug
> Components: query, sql
>Affects Versions: 2.4.2, 3.1.2
>Reporter: Petr Kadlec
>Assignee: Mark Struberg
>Priority: Major
>
> OpenJPA generates wrong SQL for a query with nested subqueries, causing the
> result to be wrong. My attempts to rewrite the query helped to get the
> correct results, even though the generated alternate queries seem not to be
> perfect. (There might a way to write them better.)
> The following query:
> {{select u from User u where u.email=:firstEmail and u<>:firstUser and exists
> (select o1 from Order o1 where o1.user=u and exists(select o2 from Order o2
> where o2.user=:firstUser and o1.productCode=o2.productCode))}}
> generates the following SQL:
> {{SELECT t0.id, t0.email, t0.name FROM users t0 WHERE (t0.email = ? AND t0.id
> <> ? AND EXISTS (SELECT t1.id FROM orders t1, orders t3 WHERE (t1.user_id =
> t0.id AND EXISTS (SELECT t2.id FROM orders t2 WHERE (t2.user_id = ? AND
> t3.product_code = t2.product_code)}}
> Notice the superfluous join to “orders t3” which causes the whole query
> result to be wrong.
> When the query is modified to replace the second nested subquery with a join
> to
> {{select u from User u where u.email=:firstEmail and u<>:firstUser and exists
> (select o1 from Order o1, Order o2 where o1.user=u and o2.user=:firstUser and
> o1.productCode=o2.productCode)}}
> the generated SQL is:
> {{SELECT t0.id, t0.email, t0.name FROM users t0 WHERE (t0.email = ? AND t0.id
> <> ? AND EXISTS (SELECT t3.id FROM users t1 CROSS JOIN orders t2, orders t3
> WHERE (t3.user_id = t0.id AND t2.user_id = ? AND t3.product_code =
> t2.product_code)))}}
> which contains a strange construction of doing a cross join to „users t1“
> (which is completely unused later). Still, this seems to return the correct
> result, at least. (In my short testing; to be honest, I do not understand
> what exactly is this construction doing, and if its semantics is better,
> equal, or worse than not doing the cross join.) However, the unnecessary join
> does seem to affect performance.
> Finally, when I rewrote the query from the other side, to:
> {{select o from Order o join o.user u where u.email=:firstEmail and
> u<>:firstUser and o.productCode in (select o1.productCode from Order o1 where
> o1.user=:firstUser)}}
> The resulting SQL is:
> {{SELECT t0.id, t0.product_code, t3.id, t3.email, t3.name FROM orders t0
> INNER JOIN users t1 ON t0.user_id = t1.id LEFT OUTER JOIN users t3 ON
> t0.user_id = t3.id WHERE (t1.email = ? AND t0.user_id <> ? AND
> t0.product_code IN (SELECT t2.product_code FROM orders t2 WHERE (t2.user_id =
> ?)))}}
> Which generates correct results, even though it _still_ contains a
> superfluous outer join to „users t3“ (used only in the result projection)
> which is identical to the previous inner join, which again affects
> performance.
> A complete reproducible project is available [at my
> Github|https://github.com/mormegil-cz/openjpa-bug-repro].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2800) StateManager field in enhanced entities are not "synthetic"
[
https://issues.apache.org/jira/browse/OPENJPA-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved OPENJPA-2800.
Resolution: Fixed
> StateManager field in enhanced entities are not "synthetic"
> ---
>
> Key: OPENJPA-2800
> URL: https://issues.apache.org/jira/browse/OPENJPA-2800
> Project: OpenJPA
> Issue Type: Bug
> Components: Enhance
>Affects Versions: 2.4.3
>Reporter: Alexander Falb
>Assignee: Mark Struberg
>Priority: Minor
> Fix For: 3.1.3
>
> Attachments: image-2020-01-15-08-12-02-066.png
>
>
> I'm using reflection to do various things on an entity-class during my unit
> tests. Because my tests are not interested in any of OpenJPAs internals, I'm
> trying to skip any field generated during enhancement. Basically I skip every
> field with where
> [Field#isSynthetic|https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/Field.html#isSynthetic--]]
> is true. The pcStateManager however does not have the flag ACC_SYNTHETIC set:
> {code:java}
> $ javap -verbose MyEntity.class
> [...]
> protected transient org.apache.openjpa.enhance.StateManager pcStateManager;
> descriptor: Lorg/apache/openjpa/enhance/StateManager;
> flags: ACC_PROTECTED, ACC_TRANSIENT
> [...]
> {code}
> According to the [JVM
> Specs|https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.8]
> {quote}[...]A class member that does not appear in the source code must be
> marked using a Synthetic attribute, or else it must have its ACC_SYNTHETIC
> flag set.[...]
> {quote}
> Is this flag intentionally not set?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OPENJPA-2800) StateManager field in enhanced entities are not "synthetic"
[
https://issues.apache.org/jira/browse/OPENJPA-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg updated OPENJPA-2800:
---
Fix Version/s: 3.1.3
> StateManager field in enhanced entities are not "synthetic"
> ---
>
> Key: OPENJPA-2800
> URL: https://issues.apache.org/jira/browse/OPENJPA-2800
> Project: OpenJPA
> Issue Type: Bug
> Components: Enhance
>Affects Versions: 2.4.3
>Reporter: Alexander Falb
>Assignee: Mark Struberg
>Priority: Minor
> Fix For: 3.1.3
>
> Attachments: image-2020-01-15-08-12-02-066.png
>
>
> I'm using reflection to do various things on an entity-class during my unit
> tests. Because my tests are not interested in any of OpenJPAs internals, I'm
> trying to skip any field generated during enhancement. Basically I skip every
> field with where
> [Field#isSynthetic|https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/Field.html#isSynthetic--]]
> is true. The pcStateManager however does not have the flag ACC_SYNTHETIC set:
> {code:java}
> $ javap -verbose MyEntity.class
> [...]
> protected transient org.apache.openjpa.enhance.StateManager pcStateManager;
> descriptor: Lorg/apache/openjpa/enhance/StateManager;
> flags: ACC_PROTECTED, ACC_TRANSIENT
> [...]
> {code}
> According to the [JVM
> Specs|https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.8]
> {quote}[...]A class member that does not appear in the source code must be
> marked using a Synthetic attribute, or else it must have its ACC_SYNTHETIC
> flag set.[...]
> {quote}
> Is this flag intentionally not set?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work started] (OPENJPA-2800) StateManager field in enhanced entities are not "synthetic"
[
https://issues.apache.org/jira/browse/OPENJPA-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on OPENJPA-2800 started by Mark Struberg.
--
> StateManager field in enhanced entities are not "synthetic"
> ---
>
> Key: OPENJPA-2800
> URL: https://issues.apache.org/jira/browse/OPENJPA-2800
> Project: OpenJPA
> Issue Type: Bug
> Components: Enhance
>Affects Versions: 2.4.3
>Reporter: Alexander Falb
>Assignee: Mark Struberg
>Priority: Minor
> Attachments: image-2020-01-15-08-12-02-066.png
>
>
> I'm using reflection to do various things on an entity-class during my unit
> tests. Because my tests are not interested in any of OpenJPAs internals, I'm
> trying to skip any field generated during enhancement. Basically I skip every
> field with where
> [Field#isSynthetic|https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/Field.html#isSynthetic--]]
> is true. The pcStateManager however does not have the flag ACC_SYNTHETIC set:
> {code:java}
> $ javap -verbose MyEntity.class
> [...]
> protected transient org.apache.openjpa.enhance.StateManager pcStateManager;
> descriptor: Lorg/apache/openjpa/enhance/StateManager;
> flags: ACC_PROTECTED, ACC_TRANSIENT
> [...]
> {code}
> According to the [JVM
> Specs|https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.8]
> {quote}[...]A class member that does not appear in the source code must be
> marked using a Synthetic attribute, or else it must have its ACC_SYNTHETIC
> flag set.[...]
> {quote}
> Is this flag intentionally not set?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (OPENJPA-2789) JDBC connection not closed when running named query in explicitly opened connection
[
https://issues.apache.org/jira/browse/OPENJPA-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324608#comment-17324608
]
Mark Struberg edited comment on OPENJPA-2789 at 4/18/21, 9:17 PM:
--
txs for the report! I did enable the 'old' behaviour which closed the
connection.
PS: the sample did not close the EM, which would also have freed the connection.
was (Author: struberg):
txs for the report! I did enable the 'old' behaviour which closed the
connection.
> JDBC connection not closed when running named query in explicitly opened
> connection
> ---
>
> Key: OPENJPA-2789
> URL: https://issues.apache.org/jira/browse/OPENJPA-2789
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc, kernel
>Affects Versions: 2.4.3
> Environment: Windows 7, Java 8 64 Bit, openJPA 2.4.3, maven 3.6.1
>Reporter: Wolfgang Rupprath
>Assignee: Mark Struberg
>Priority: Critical
> Fix For: 3.1.3
>
> Attachments: jpa243bug.zip
>
>
> When executing a named query against a database within an explicitly opened
> transaction, after 10 successful executions the program hangs.
> The problem occured when we started migrating from openJPA 2.2.0 to 2.4.3
> I have tested against DB2 and Oracle databases with the same results. I
> suspect the problem arises for any relational DB.
> I have attached a simple maven project that will demonstrate the bug.
> Under 2.2.0, the test runs fine.
> When the query is changed to a native query, the test runs fine.
> Debugging the openJPA code, I found suspicious code in class
> org.apache.openjpa.jdbc.kernel.JDBCStoreQuery, method executeBulkOperation,
> line 587:
> try {
> {{ if (conn.getAutoCommit())}}
> conn.close();
> {{ } catch (SQLException se) {}}{{}}}{{}}
> The connection in case will not be returned to the pool as the conn.close()
> is not executed wthin a transaction. So when committing, the ref count will
> not be zero when the transaction ends and the underlying JDBC connection will
> not be closed.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2789) JDBC connection not closed when running named query in explicitly opened connection
[
https://issues.apache.org/jira/browse/OPENJPA-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved OPENJPA-2789.
Resolution: Fixed
txs for the report! I did enable the 'old' behaviour which closed the
connection.
> JDBC connection not closed when running named query in explicitly opened
> connection
> ---
>
> Key: OPENJPA-2789
> URL: https://issues.apache.org/jira/browse/OPENJPA-2789
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc, kernel
>Affects Versions: 2.4.3
> Environment: Windows 7, Java 8 64 Bit, openJPA 2.4.3, maven 3.6.1
>Reporter: Wolfgang Rupprath
>Assignee: Mark Struberg
>Priority: Critical
> Fix For: 3.1.3
>
> Attachments: jpa243bug.zip
>
>
> When executing a named query against a database within an explicitly opened
> transaction, after 10 successful executions the program hangs.
> The problem occured when we started migrating from openJPA 2.2.0 to 2.4.3
> I have tested against DB2 and Oracle databases with the same results. I
> suspect the problem arises for any relational DB.
> I have attached a simple maven project that will demonstrate the bug.
> Under 2.2.0, the test runs fine.
> When the query is changed to a native query, the test runs fine.
> Debugging the openJPA code, I found suspicious code in class
> org.apache.openjpa.jdbc.kernel.JDBCStoreQuery, method executeBulkOperation,
> line 587:
> try {
> {{ if (conn.getAutoCommit())}}
> conn.close();
> {{ } catch (SQLException se) {}}{{}}}{{}}
> The connection in case will not be returned to the pool as the conn.close()
> is not executed wthin a transaction. So when committing, the ref count will
> not be zero when the transaction ends and the underlying JDBC connection will
> not be closed.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OPENJPA-2865) [Oracle] use native java.time JDBC features
[
https://issues.apache.org/jira/browse/OPENJPA-2865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324554#comment-17324554
]
Mark Struberg commented on OPENJPA-2865:
fine, closing it then.
> [Oracle] use native java.time JDBC features
> ---
>
> Key: OPENJPA-2865
> URL: https://issues.apache.org/jira/browse/OPENJPA-2865
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 3.1.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.1.3
>
>
> For the supported java.time types like {{LocalDate}}, LocalDateTime,
> LocalTime, OffsetTime and OffsetDateTime we should make use of native JDBC
> driver features to avoid internal conversions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2865) [Oracle] use native java.time JDBC features
[
https://issues.apache.org/jira/browse/OPENJPA-2865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved OPENJPA-2865.
Resolution: Fixed
> [Oracle] use native java.time JDBC features
> ---
>
> Key: OPENJPA-2865
> URL: https://issues.apache.org/jira/browse/OPENJPA-2865
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 3.1.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.1.3
>
>
> For the supported java.time types like {{LocalDate}}, LocalDateTime,
> LocalTime, OffsetTime and OffsetDateTime we should make use of native JDBC
> driver features to avoid internal conversions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OPENJPA-2865) [Oracle] use native java.time JDBC features
[
https://issues.apache.org/jira/browse/OPENJPA-2865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324473#comment-17324473
]
Mark Struberg commented on OPENJPA-2865:
[~rmannibucau] [~ilgrosso] wdyt? should we change the type or leave it as
{{TIMESTAMP}} for Oracle which actually does not contain a time zone? Not sure
how much OffsetTime is really used. But if so, then using a OffsetDateTime with
a fixed jan-01-1970 would be probably better?
> [Oracle] use native java.time JDBC features
> ---
>
> Key: OPENJPA-2865
> URL: https://issues.apache.org/jira/browse/OPENJPA-2865
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 3.1.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.1.3
>
>
> For the supported java.time types like {{LocalDate}}, LocalDateTime,
> LocalTime, OffsetTime and OffsetDateTime we should make use of native JDBC
> driver features to avoid internal conversions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2866) [Oracle] add GenerationType#IDENTITY support for Oracle
[
https://issues.apache.org/jira/browse/OPENJPA-2866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved OPENJPA-2866.
Resolution: Fixed
> [Oracle] add GenerationType#IDENTITY support for Oracle
> ---
>
> Key: OPENJPA-2866
> URL: https://issues.apache.org/jira/browse/OPENJPA-2866
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 3.1.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.1.3
>
>
> Our {{OracleDictionary}} did not support
> {{javax.persistence.GenerationType#IDENTITY}}. This is clearly a bug. We
> should create a {{"GENERATED ALWAYS AS IDENTITY"}} column.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OPENJPA-2865) [Oracle] use native java.time JDBC features
[
https://issues.apache.org/jira/browse/OPENJPA-2865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17318550#comment-17318550
]
Mark Struberg commented on OPENJPA-2865:
the only question left is how to treat {{java.time.OffsetTime}}? Right now we
map it to a {{DATE}} column in Oracle. There is no native {{TIME WITH TIME
ZONE}} type in Oracle, but only {{TIMESTAMP WITH TIME ZONE}}.
Should we rather use the laster with a fixed date pinned to {{1970-01-01}} or
keep it with {{DATE}} as we do right now?
> [Oracle] use native java.time JDBC features
> ---
>
> Key: OPENJPA-2865
> URL: https://issues.apache.org/jira/browse/OPENJPA-2865
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 3.1.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.1.3
>
>
> For the supported java.time types like {{LocalDate}}, LocalDateTime,
> LocalTime, OffsetTime and OffsetDateTime we should make use of native JDBC
> driver features to avoid internal conversions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OPENJPA-2866) [Oracle] add GenerationType#IDENTITY support for Oracle
Mark Struberg created OPENJPA-2866:
--
Summary: [Oracle] add GenerationType#IDENTITY support for Oracle
Key: OPENJPA-2866
URL: https://issues.apache.org/jira/browse/OPENJPA-2866
Project: OpenJPA
Issue Type: Bug
Components: jdbc
Affects Versions: 3.1.2
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 3.1.3
Our {{OracleDictionary}} did not support
{{javax.persistence.GenerationType#IDENTITY}}. This is clearly a bug. We should
create a {{"GENERATED ALWAYS AS IDENTITY"}} column.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OPENJPA-2865) [Oracle] use native java.time JDBC features
Mark Struberg created OPENJPA-2865:
--
Summary: [Oracle] use native java.time JDBC features
Key: OPENJPA-2865
URL: https://issues.apache.org/jira/browse/OPENJPA-2865
Project: OpenJPA
Issue Type: Bug
Components: jdbc
Affects Versions: 3.1.2
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 3.1.3
For the supported java.time types like {{LocalDate}}, LocalDateTime, LocalTime,
OffsetTime and OffsetDateTime we should make use of native JDBC driver features
to avoid internal conversions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2864) respect the Columns precision when persisting a java.sql.Timestamp value
[
https://issues.apache.org/jira/browse/OPENJPA-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved OPENJPA-2864.
Resolution: Fixed
> respect the Columns precision when persisting a java.sql.Timestamp value
>
>
> Key: OPENJPA-2864
> URL: https://issues.apache.org/jira/browse/OPENJPA-2864
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 3.1.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.1.3
>
>
> right now we use the {{datePrecision}} for rounding/truncating
> {{java.sql.Timestamp}} values.
> The value should still be used as default, but if a Column has a specific
> precision configured, then we should use that.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2863) java.time.LocalDateTime in Oracle gets rounded to just 3 digits
[
https://issues.apache.org/jira/browse/OPENJPA-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved OPENJPA-2863.
Fix Version/s: 3.1.3
Resolution: Fixed
> java.time.LocalDateTime in Oracle gets rounded to just 3 digits
> ---
>
> Key: OPENJPA-2863
> URL: https://issues.apache.org/jira/browse/OPENJPA-2863
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Affects Versions: 3.1.2
>Reporter: Karl Grosse
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.1.3
>
>
> Having a column like
>
> {code:java}
> @NotNull
> @Column(name = "awayUntil", nullable = false)
> private LocalDateTime awayUntil;
> {code}
> which we set to
> {code:java}
> awayUntil = LocalDate.of(2021, 4, 8).atTime(LocalTime.MAX);
> {code}
> gets somehow rounded to 2021-4-9 00:00:00,00 after persisting into the
> Oracle DB.
> The type of the column in Oracle is Timestamp(6).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OPENJPA-2864) respect the Columns precision when persisting a java.sql.Timestamp value
Mark Struberg created OPENJPA-2864:
--
Summary: respect the Columns precision when persisting a
java.sql.Timestamp value
Key: OPENJPA-2864
URL: https://issues.apache.org/jira/browse/OPENJPA-2864
Project: OpenJPA
Issue Type: Bug
Components: jdbc
Affects Versions: 3.1.2
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 3.1.3
right now we use the {{datePrecision}} for rounding/truncating
{{java.sql.Timestamp}} values.
The value should still be used as default, but if a Column has a specific
precision configured, then we should use that.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OPENJPA-2863) java.time.LocalDateTime in Oracle gets rounded to just 3 digits
[
https://issues.apache.org/jira/browse/OPENJPA-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17317158#comment-17317158
]
Mark Struberg commented on OPENJPA-2863:
The constant {{LocalTime.MAX}} uses {{9}} for nanoseconds and your
column is only {{TIMESTAMP(6)}} thus the value gets rounded up. That part is
actually ok.
But I found another bug which is likely very related. Even the following code
will round over to the next day:
{noformat}
// zero out the nanos part and truncate to micros essentially:
awayUntil = LocalDate.of(2021, 4, 8).atTime(LocalTime.of(23, 59, 59, 66000);
{noformat}
This is is the result of a bug we introduced a long time ago and also affects
our handling of {{java.sql.Timestamp}}. We round those values to MILLIS and not
to MICROS which is the default for Oracle.
I gonna fix that in {{OracleDictionary}}, for retaining the old 3 fraction
digits behaviour one can use the configuration in persistence.xml properties
section to use 1_000_000 nanosecond precision:
{noformat}
{noformat}
> java.time.LocalDateTime in Oracle gets rounded to just 3 digits
> ---
>
> Key: OPENJPA-2863
> URL: https://issues.apache.org/jira/browse/OPENJPA-2863
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Affects Versions: 3.1.2
>Reporter: Karl Grosse
>Assignee: Mark Struberg
>Priority: Major
>
> Having a column like
>
> {code:java}
> @NotNull
> @Column(name = "awayUntil", nullable = false)
> private LocalDateTime awayUntil;
> {code}
> which we set to
> {code:java}
> awayUntil = LocalDate.of(2021, 4, 8).atTime(LocalTime.MAX);
> {code}
> gets somehow rounded to 2021-4-9 00:00:00,00 after persisting into the
> Oracle DB.
> The type of the column in Oracle is Timestamp(6).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OPENJPA-2863) java.time.LocalDateTime in Oracle gets rounded to just 3 digits
[
https://issues.apache.org/jira/browse/OPENJPA-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg updated OPENJPA-2863:
---
Summary: java.time.LocalDateTime in Oracle gets rounded to just 3 digits
(was: java.time.LocalDateTime at LocalTime.MAX in Oracle gets rounded to the
next day atStartOfDay)
> java.time.LocalDateTime in Oracle gets rounded to just 3 digits
> ---
>
> Key: OPENJPA-2863
> URL: https://issues.apache.org/jira/browse/OPENJPA-2863
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Affects Versions: 3.1.2
>Reporter: Karl Grosse
>Assignee: Mark Struberg
>Priority: Major
>
> Having a column like
>
> {code:java}
> @NotNull
> @Column(name = "awayUntil", nullable = false)
> private LocalDateTime awayUntil;
> {code}
> which we set to
> {code:java}
> awayUntil = LocalDate.of(2021, 4, 8).atTime(LocalTime.MAX);
> {code}
> gets somehow rounded to 2021-4-9 00:00:00,00 after persisting into the
> Oracle DB.
> The type of the column in Oracle is Timestamp(6).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (OPENJPA-2863) java.time.LocalDateTime at LocalTime.MAX in Oracle gets rounded to the next day atStartOfDay
[
https://issues.apache.org/jira/browse/OPENJPA-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg reassigned OPENJPA-2863:
--
Assignee: Mark Struberg
> java.time.LocalDateTime at LocalTime.MAX in Oracle gets rounded to the next
> day atStartOfDay
>
>
> Key: OPENJPA-2863
> URL: https://issues.apache.org/jira/browse/OPENJPA-2863
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Affects Versions: 3.1.2
>Reporter: Karl Grosse
>Assignee: Mark Struberg
>Priority: Major
>
> Having a column like
>
> {code:java}
> @NotNull
> @Column(name = "awayUntil", nullable = false)
> private LocalDateTime awayUntil;
> {code}
> which we set to
> {code:java}
> awayUntil = LocalDate.of(2021, 4, 8).atTime(LocalTime.MAX);
> {code}
> gets somehow rounded to 2021-4-9 00:00:00,00 after persisting into the
> Oracle DB.
> The type of the column in Oracle is Timestamp(6).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OPENJPA-2797) SynchronizedMapping does not detect existing sequence
[
https://issues.apache.org/jira/browse/OPENJPA-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17315983#comment-17315983
]
Mark Struberg commented on OPENJPA-2797:
hi! does that sequence exist in another schema? we might have an issue in that
area.
> SynchronizedMapping does not detect existing sequence
> -
>
> Key: OPENJPA-2797
> URL: https://issues.apache.org/jira/browse/OPENJPA-2797
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 3.1.0
> Environment: TomEE 8.0, PostGreSQL 10
>Reporter: Christophe Noel
>Priority: Major
>
> When doing the JDBC Synchronization, the existing sequence are not detected
> and an ReportingSQLException is reported.
> The SequenceGenerator and column definition is shown below. Note that the
> database is PostGreSQL 10 and the tables/sequences are located in a dedicated
> YYY schema.
>
> {code:java}
> @Id
> @SequenceGenerator(name="XXX_SEQUENCE",sequenceName="XXX_SEQ",
> initialValue=SequenceConstants.INITIAL_SEQUENCE_VALUE, schema = "YYY")
> @GeneratedValue(strategy = GenerationType.SEQUENCE, generator="XXX_SEQUENCE")
> @Column(name = "ID")
> private long id;{code}
>
> Properties:
>
> {code:java}
> value="create"/>
> value="buildSchema(ForeignKeys=true)"/>{code}
>
> Exception reported:
>
> {code:java}
> Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: ERROR: relation
> "xxx_seq" already exists {stmnt 392461001 CREATE SEQUENCE
> information_schema.XXX_SEQ START WITH 1000 INCREMENT BY 50} [code=0,
> state=42P07]
> at
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:219)
> at
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:203)
> at
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$700(LoggingConnectionDecorator.java:58)
> at
> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingStatement.executeUpdate(LoggingConnectionDecorator.java:955)
> at
> org.apache.openjpa.lib.jdbc.DelegatingStatement.executeUpdate(DelegatingStatement.java:123)
> at
> org.apache.openjpa.jdbc.schema.SchemaTool.executeSQL(SchemaTool.java:1377)
> at
> org.apache.openjpa.jdbc.schema.SchemaTool.createSequence(SchemaTool.java:1137)
> at
> org.apache.openjpa.jdbc.schema.SchemaTool.buildSchema(SchemaTool.java:580)
> at org.apache.openjpa.jdbc.schema.SchemaTool.add(SchemaTool.java:562)
> at org.apache.openjpa.jdbc.schema.SchemaTool.add(SchemaTool.java:401)
> at org.apache.openjpa.jdbc.schema.SchemaTool.run(SchemaTool.java:373)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OPENJPA-2789) JDBC connection not closed when running named query in explicitly opened connection
[
https://issues.apache.org/jira/browse/OPENJPA-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg updated OPENJPA-2789:
---
Fix Version/s: 3.1.3
> JDBC connection not closed when running named query in explicitly opened
> connection
> ---
>
> Key: OPENJPA-2789
> URL: https://issues.apache.org/jira/browse/OPENJPA-2789
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc, kernel
>Affects Versions: 2.4.3
> Environment: Windows 7, Java 8 64 Bit, openJPA 2.4.3, maven 3.6.1
>Reporter: Wolfgang Rupprath
>Assignee: Mark Struberg
>Priority: Critical
> Fix For: 3.1.3
>
> Attachments: jpa243bug.zip
>
>
> When executing a named query against a database within an explicitly opened
> transaction, after 10 successful executions the program hangs.
> The problem occured when we started migrating from openJPA 2.2.0 to 2.4.3
> I have tested against DB2 and Oracle databases with the same results. I
> suspect the problem arises for any relational DB.
> I have attached a simple maven project that will demonstrate the bug.
> Under 2.2.0, the test runs fine.
> When the query is changed to a native query, the test runs fine.
> Debugging the openJPA code, I found suspicious code in class
> org.apache.openjpa.jdbc.kernel.JDBCStoreQuery, method executeBulkOperation,
> line 587:
> try {
> {{ if (conn.getAutoCommit())}}
> conn.close();
> {{ } catch (SQLException se) {}}{{}}}{{}}
> The connection in case will not be returned to the pool as the conn.close()
> is not executed wthin a transaction. So when committing, the ref count will
> not be zero when the transaction ends and the underlying JDBC connection will
> not be closed.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (OPENJPA-2789) JDBC connection not closed when running named query in explicitly opened connection
[
https://issues.apache.org/jira/browse/OPENJPA-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg reassigned OPENJPA-2789:
--
Assignee: Mark Struberg
> JDBC connection not closed when running named query in explicitly opened
> connection
> ---
>
> Key: OPENJPA-2789
> URL: https://issues.apache.org/jira/browse/OPENJPA-2789
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc, kernel
>Affects Versions: 2.4.3
> Environment: Windows 7, Java 8 64 Bit, openJPA 2.4.3, maven 3.6.1
>Reporter: Wolfgang Rupprath
>Assignee: Mark Struberg
>Priority: Critical
> Attachments: jpa243bug.zip
>
>
> When executing a named query against a database within an explicitly opened
> transaction, after 10 successful executions the program hangs.
> The problem occured when we started migrating from openJPA 2.2.0 to 2.4.3
> I have tested against DB2 and Oracle databases with the same results. I
> suspect the problem arises for any relational DB.
> I have attached a simple maven project that will demonstrate the bug.
> Under 2.2.0, the test runs fine.
> When the query is changed to a native query, the test runs fine.
> Debugging the openJPA code, I found suspicious code in class
> org.apache.openjpa.jdbc.kernel.JDBCStoreQuery, method executeBulkOperation,
> line 587:
> try {
> {{ if (conn.getAutoCommit())}}
> conn.close();
> {{ } catch (SQLException se) {}}{{}}}{{}}
> The connection in case will not be returned to the pool as the conn.close()
> is not executed wthin a transaction. So when committing, the ref count will
> not be zero when the transaction ends and the underlying JDBC connection will
> not be closed.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OPENJPA-2800) StateManager field in enhanced entities are not "synthetic"
[
https://issues.apache.org/jira/browse/OPENJPA-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17315982#comment-17315982
]
Mark Struberg commented on OPENJPA-2800:
[~elexx] do you want to try to ship a patch for it? txs!
> StateManager field in enhanced entities are not "synthetic"
> ---
>
> Key: OPENJPA-2800
> URL: https://issues.apache.org/jira/browse/OPENJPA-2800
> Project: OpenJPA
> Issue Type: Bug
> Components: Enhance
>Affects Versions: 2.4.3
>Reporter: Alexander Falb
>Assignee: Mark Struberg
>Priority: Minor
> Attachments: image-2020-01-15-08-12-02-066.png
>
>
> I'm using reflection to do various things on an entity-class during my unit
> tests. Because my tests are not interested in any of OpenJPAs internals, I'm
> trying to skip any field generated during enhancement. Basically I skip every
> field with where
> [Field#isSynthetic|https://docs.oracle.com/javase/8/docs/api/java/lang/reflect/Field.html#isSynthetic--]]
> is true. The pcStateManager however does not have the flag ACC_SYNTHETIC set:
> {code:java}
> $ javap -verbose MyEntity.class
> [...]
> protected transient org.apache.openjpa.enhance.StateManager pcStateManager;
> descriptor: Lorg/apache/openjpa/enhance/StateManager;
> flags: ACC_PROTECTED, ACC_TRANSIENT
> [...]
> {code}
> According to the [JVM
> Specs|https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.8]
> {quote}[...]A class member that does not appear in the source code must be
> marked using a Synthetic attribute, or else it must have its ACC_SYNTHETIC
> flag set.[...]
> {quote}
> Is this flag intentionally not set?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OPENJPA-2806) PESSIMISTIC_READ takes out exclusive lock on Postgres
[
https://issues.apache.org/jira/browse/OPENJPA-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17315980#comment-17315980
]
Mark Struberg commented on OPENJPA-2806:
Hi [~pveselov] That could have something to do that PostgreSQL didn't support
setQueryTimeout properly for a long time. Since pg10 it's nicely supported and
I enabled it in our {{PostgresDictionary}} a few days ago in OPENJPA-2860. Can
you please retest it with 3.1.3-SNAPSHOT? txs!
> PESSIMISTIC_READ takes out exclusive lock on Postgres
> -
>
> Key: OPENJPA-2806
> URL: https://issues.apache.org/jira/browse/OPENJPA-2806
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
>Affects Versions: 2.4.2, 3.0.0, 3.1.0
>Reporter: Pawel Veselov
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.1.3
>
> Attachments: openjpa-lock.zip
>
>
> I've found out that using PESSIMISTIC_READ on an entity with postgres
> uses 'for update' lock, which is actually exclusive.
> I understand JPA specification says that it's permissible to do that,
> but I really need a shared lock for what I'm trying to achieve.
> Is it possible to control somehow? I've had to resolve to using native
> queries, and I'd like to avoid this as much as possible...
> Attached is a test.
> Change App.java to control database properties for connection (top of
> `main()`)
> Run App.class to execute the test. If the lock taken by OpenJPA is exclusive,
> then native query will fail (with an exception).
> I'm testing on Postgres 9.6
> Tested with 2.4.2, 3.0.0 and 3.1.0
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OPENJPA-2806) PESSIMISTIC_READ takes out exclusive lock on Postgres
[ https://issues.apache.org/jira/browse/OPENJPA-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated OPENJPA-2806: --- Fix Version/s: 3.1.3 > PESSIMISTIC_READ takes out exclusive lock on Postgres > - > > Key: OPENJPA-2806 > URL: https://issues.apache.org/jira/browse/OPENJPA-2806 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Affects Versions: 2.4.2, 3.0.0, 3.1.0 >Reporter: Pawel Veselov >Assignee: Mark Struberg >Priority: Major > Fix For: 3.1.3 > > Attachments: openjpa-lock.zip > > > I've found out that using PESSIMISTIC_READ on an entity with postgres > uses 'for update' lock, which is actually exclusive. > I understand JPA specification says that it's permissible to do that, > but I really need a shared lock for what I'm trying to achieve. > Is it possible to control somehow? I've had to resolve to using native > queries, and I'd like to avoid this as much as possible... > Attached is a test. > Change App.java to control database properties for connection (top of > `main()`) > Run App.class to execute the test. If the lock taken by OpenJPA is exclusive, > then native query will fail (with an exception). > I'm testing on Postgres 9.6 > Tested with 2.4.2, 3.0.0 and 3.1.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OPENJPA-2806) PESSIMISTIC_READ takes out exclusive lock on Postgres
[ https://issues.apache.org/jira/browse/OPENJPA-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned OPENJPA-2806: -- Assignee: Mark Struberg > PESSIMISTIC_READ takes out exclusive lock on Postgres > - > > Key: OPENJPA-2806 > URL: https://issues.apache.org/jira/browse/OPENJPA-2806 > Project: OpenJPA > Issue Type: Bug > Components: kernel >Affects Versions: 2.4.2, 3.0.0, 3.1.0 >Reporter: Pawel Veselov >Assignee: Mark Struberg >Priority: Major > Attachments: openjpa-lock.zip > > > I've found out that using PESSIMISTIC_READ on an entity with postgres > uses 'for update' lock, which is actually exclusive. > I understand JPA specification says that it's permissible to do that, > but I really need a shared lock for what I'm trying to achieve. > Is it possible to control somehow? I've had to resolve to using native > queries, and I'd like to avoid this as much as possible... > Attached is a test. > Change App.java to control database properties for connection (top of > `main()`) > Run App.class to execute the test. If the lock taken by OpenJPA is exclusive, > then native query will fail (with an exception). > I'm testing on Postgres 9.6 > Tested with 2.4.2, 3.0.0 and 3.1.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2731) Problems with Boolean Representation with Postgres
[ https://issues.apache.org/jira/browse/OPENJPA-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-2731. Fix Version/s: 3.1.3 Resolution: Fixed > Problems with Boolean Representation with Postgres > -- > > Key: OPENJPA-2731 > URL: https://issues.apache.org/jira/browse/OPENJPA-2731 > Project: OpenJPA > Issue Type: Bug > Components: jdbc >Affects Versions: 2.2.2 >Reporter: Jody Grassel >Assignee: Jody Grassel >Priority: Major > Labels: easyfix > Fix For: 2.2.3, 3.1.3 > > Attachments: patch_2.2.x.txt > > > OPENJPA-2558 addressed, in general, boolean representations on the database > (native Boolean column types, as an int(0,1), as a string, as a char, etc), > but had coverage gaps with respect to the supported platforms. Postgres is > one of those platforms. Its dictionary class still overrode setBoolean(), > but did not equally override getBoolean() which introduced a conflict. > I'm proposing an update which removes the setBoolean() method from the > Postgres dbdictionary, as well as adding the ability for a database platform > to declare a default boolean representation type (preserving the INT10 > default, but setting Postgres' to BooleanRepresentation in order to match > what the schemagenerator for postgres creates). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2861) select sum(CASE x WHEN x THEN 1 ELSE 0 ) returns String instead of Long.
[
https://issues.apache.org/jira/browse/OPENJPA-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved OPENJPA-2861.
Resolution: Fixed
This was quite a nasty bug. I changed a lot of the Raw handling and also fixed
{{BooleanRepresentation}} handling in {{Lit}}.
> select sum(CASE x WHEN x THEN 1 ELSE 0 ) returns String instead of Long.
>
>
> Key: OPENJPA-2861
> URL: https://issues.apache.org/jira/browse/OPENJPA-2861
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
>Affects Versions: 3.1.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.1.3
>
>
> It seems that a few operations in {{JDBCExpressionFactory}} often calls
> {{getLiteralRawString}} which destroys the information about any real types
> in a query and replaces it with a {{Raw}} which is always of type
> {{java.lang.String}}.
> This breaks the following query, which wrongly returns a string instead of a
> Long:
> {noformat}
> final TypedQuery q
>= em.createQuery("select SUM(CASE ae.stringVal WHEN 'bare' THEN 1 ELSE 0
> END) from AggEntity AS ae", Long.class);
> final Long sumC = q.getSingleResult();{noformat}
> This only affects us since I fixed {{UnaryOp}} to not return the native JDBC
> vendor type of a given column but uses the {{val.getType()}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2862) select SUM doesn't return spec defined types
[
https://issues.apache.org/jira/browse/OPENJPA-2862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved OPENJPA-2862.
Resolution: Fixed
> select SUM doesn't return spec defined types
>
>
> Key: OPENJPA-2862
> URL: https://issues.apache.org/jira/browse/OPENJPA-2862
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
>Affects Versions: 3.1.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.1.3
>
>
> As per spec section 4.8.5 Aggregate Functions in the SELECT Clause we need
> to handle a few types in a special way
> {noformat}
> SUM returns Long when applied to state fields of integral types (other than
> BigInteger); Dou- ble when applied to state fields of floating point types;
> BigInteger when applied to state fields of type BigInteger; and BigDecimal
> when applied to state fields of type BigDecimal.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OPENJPA-2862) select SUM doesn't return spec defined types
Mark Struberg created OPENJPA-2862:
--
Summary: select SUM doesn't return spec defined types
Key: OPENJPA-2862
URL: https://issues.apache.org/jira/browse/OPENJPA-2862
Project: OpenJPA
Issue Type: Bug
Components: kernel
Affects Versions: 3.1.2
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 3.1.3
As per spec section 4.8.5 Aggregate Functions in the SELECT Clause we need to
handle a few types in a special way
{noformat}
SUM returns Long when applied to state fields of integral types (other than
BigInteger); Dou- ble when applied to state fields of floating point types;
BigInteger when applied to state fields of type BigInteger; and BigDecimal when
applied to state fields of type BigDecimal.
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OPENJPA-2861) select sum(CASE x WHEN x THEN 1 ELSE 0 ) returns String instead of Long.
Mark Struberg created OPENJPA-2861:
--
Summary: select sum(CASE x WHEN x THEN 1 ELSE 0 ) returns String
instead of Long.
Key: OPENJPA-2861
URL: https://issues.apache.org/jira/browse/OPENJPA-2861
Project: OpenJPA
Issue Type: Bug
Components: kernel
Affects Versions: 3.1.2
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 3.1.3
It seems that a few operations in {{JDBCExpressionFactory}} often calls
{{getLiteralRawString}} which destroys the information about any real types in
a query and replaces it with a {{Raw}} which is always of type
{{java.lang.String}}.
This breaks the following query, which wrongly returns a string instead of a
Long:
{noformat}
final TypedQuery q
= em.createQuery("select SUM(CASE ae.stringVal WHEN 'bare' THEN 1 ELSE 0
END) from AggEntity AS ae", Long.class);
final Long sumC = q.getSingleResult();{noformat}
This only affects us since I fixed {{UnaryOp}} to not return the native JDBC
vendor type of a given column but uses the {{val.getType()}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OPENJPA-2767) Incomplete ValueMapDiscriminatorStrategy cache
[ https://issues.apache.org/jira/browse/OPENJPA-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17315102#comment-17315102 ] Mark Struberg commented on OPENJPA-2767: Hi [~dazeydev] I think this is finally resolved, isn't? > Incomplete ValueMapDiscriminatorStrategy cache > --- > > Key: OPENJPA-2767 > URL: https://issues.apache.org/jira/browse/OPENJPA-2767 > Project: OpenJPA > Issue Type: Bug >Reporter: Will Dazey >Assignee: Will Dazey >Priority: Minor > Fix For: 3.1.3 > > Attachments: OJ2767_2.2.x_v4.patch, OJ2767_2.2.x_v4_p2.patch > > Time Spent: 1h 40m > Remaining Estimate: 0h > > There exists the possibility that the discriminator class cache in > ValueMapDiscriminatorStrategy was originally created before the server fully > loaded all classes. If this happens, the cache is incomplete and needs to be > rebuilt. A simple enough strategy would be to just try rebuilding the cache, > before giving up and throwing a CNFE, and check again. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2860) [Postgres] use setQueryTimeout for PostgreSQL >= 10
[
https://issues.apache.org/jira/browse/OPENJPA-2860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved OPENJPA-2860.
Resolution: Fixed
{{supportsQueryTimeout}} is now enabled by default for PostgreSQL 10 and later.
You can manually configure (disable) this by setting the following property in
a persistence-unit in your persistence.xml:
{noformat}
{noformat}
> [Postgres] use setQueryTimeout for PostgreSQL >= 10
> ---
>
> Key: OPENJPA-2860
> URL: https://issues.apache.org/jira/browse/OPENJPA-2860
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 3.1.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.1.3
>
>
> PostgreSQL JDBC driver did not support {{setQueryTimeout}} properly for a
> quite long time. But since v10 it is working fine. We can thus enable
> {{DBDictionary#supportsQueryTimeout}} for {{PostgresDictionary}} and only
> disable it if majorVersion < 10.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OPENJPA-2860) [Postgres] use setQueryTimeout for PostgreSQL >= 10
Mark Struberg created OPENJPA-2860:
--
Summary: [Postgres] use setQueryTimeout for PostgreSQL >= 10
Key: OPENJPA-2860
URL: https://issues.apache.org/jira/browse/OPENJPA-2860
Project: OpenJPA
Issue Type: Bug
Components: jdbc
Affects Versions: 3.1.2
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 3.1.3
PostgreSQL JDBC driver did not support {{setQueryTimeout}} properly for a quite
long time. But since v10 it is working fine. We can thus enable
{{DBDictionary#supportsQueryTimeout}} for {{PostgresDictionary}} and only
disable it if majorVersion < 10.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OPENJPA-1594) Tests not handling new QueryTimeOut and LockTimeOut exceptions correctly
[
https://issues.apache.org/jira/browse/OPENJPA-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved OPENJPA-1594.
Fix Version/s: 3.1.3
Resolution: Fixed
The tests do run for all Databases who has
{{DBDictionaries#supportsQueryTimeout}} enabled.
> Tests not handling new QueryTimeOut and LockTimeOut exceptions correctly
>
>
> Key: OPENJPA-1594
> URL: https://issues.apache.org/jira/browse/OPENJPA-1594
> Project: OpenJPA
> Issue Type: Sub-task
> Components: jdbc, jpa, kernel, query, sql
>Affects Versions: 2.0.0, 2.1.1, 2.2.0, 2.3.0
>Reporter: Donald Woods
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.1.3
>
>
> Problems with TestTimeoutException due to changes introduced by OPENJPA-1565.
> Tests were disabled for DB2 and Oracle in r924867.
> Still seeing test failures for HSQLDB, MSSQL and MySQL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (OPENJPA-1594) Tests not handling new QueryTimeOut and LockTimeOut exceptions correctly
[ https://issues.apache.org/jira/browse/OPENJPA-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned OPENJPA-1594: -- Assignee: Mark Struberg > Tests not handling new QueryTimeOut and LockTimeOut exceptions correctly > > > Key: OPENJPA-1594 > URL: https://issues.apache.org/jira/browse/OPENJPA-1594 > Project: OpenJPA > Issue Type: Sub-task > Components: jdbc, jpa, kernel, query, sql >Affects Versions: 2.0.0, 2.1.1, 2.2.0, 2.3.0 >Reporter: Donald Woods >Assignee: Mark Struberg >Priority: Major > > Problems with TestTimeoutException due to changes introduced by OPENJPA-1565. > Tests were disabled for DB2 and Oracle in r924867. > Still seeing test failures for HSQLDB, MSSQL and MySQL. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OPENJPA-2808) SchemaTool action DROP doesn't drop Indexes created with @Index
[
https://issues.apache.org/jira/browse/OPENJPA-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17314689#comment-17314689
]
Mark Struberg commented on OPENJPA-2808:
Hi [~solomax] I'd like to include this patch in OpenJPA-3.1.3, is there
anything I can help you with? The patch imo looks rather fine, we just need the
unit test - thanks!
> SchemaTool action DROP doesn't drop Indexes created with @Index
> ---
>
> Key: OPENJPA-2808
> URL: https://issues.apache.org/jira/browse/OPENJPA-2808
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
>Affects Versions: 3.1.1
>Reporter: Mark Struberg
>Assignee: Maxim Solodovnik
>Priority: Major
> Fix For: 3.1.3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When using {{@Index(name="IFK_SOMEFK",...}} we should also drop this when
> generating the DROP statement with our SchemaTool.
> e.g. when setting
> {noformat}
>
> org.apache.openjpa
> openjpa-maven-plugin
> ${openjpa.version}
>
> drop
>
>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2665) refactore code to use more Java7 features.
[ https://issues.apache.org/jira/browse/OPENJPA-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-2665. Resolution: Fixed > refactore code to use more Java7 features. > -- > > Key: OPENJPA-2665 > URL: https://issues.apache.org/jira/browse/OPENJPA-2665 > Project: OpenJPA > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 3.1.3 > > > Refactor code to use more Java7 features. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2648) hsqldb @Id long create table as interger instead of bigint
[ https://issues.apache.org/jira/browse/OPENJPA-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-2648. Fix Version/s: 3.1.3 Resolution: Fixed > hsqldb @Id long create table as interger instead of bigint > -- > > Key: OPENJPA-2648 > URL: https://issues.apache.org/jira/browse/OPENJPA-2648 > Project: OpenJPA > Issue Type: Bug >Affects Versions: 2.4.1 > Environment: Windows 7 > Java 1.8.0_65 >Reporter: Bruno >Assignee: Mark Struberg >Priority: Blocker > Fix For: 3.1.3 > > > I've got an entity with Long as @Id. > OpenJPA creates database in a hsqldb environment. > The query that created table is : create table toto id integer identity. > It should be create table toto id bigint identity. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OPENJPA-2648) hsqldb @Id long create table as interger instead of bigint
[ https://issues.apache.org/jira/browse/OPENJPA-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17314492#comment-17314492 ] Mark Struberg commented on OPENJPA-2648: there was indeed a mapping in the HSQLDictionary which mapped it that way. It was from 2006 and hsqldb now perfectly supports BIGINT natively. So I will remove this special handling which makes it fall back to BIGINT for long. > hsqldb @Id long create table as interger instead of bigint > -- > > Key: OPENJPA-2648 > URL: https://issues.apache.org/jira/browse/OPENJPA-2648 > Project: OpenJPA > Issue Type: Bug >Affects Versions: 2.4.1 > Environment: Windows 7 > Java 1.8.0_65 >Reporter: Bruno >Assignee: Mark Struberg >Priority: Blocker > > I've got an entity with Long as @Id. > OpenJPA creates database in a hsqldb environment. > The query that created table is : create table toto id integer identity. > It should be create table toto id bigint identity. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OPENJPA-2648) hsqldb @Id long create table as interger instead of bigint
[ https://issues.apache.org/jira/browse/OPENJPA-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned OPENJPA-2648: -- Assignee: Mark Struberg > hsqldb @Id long create table as interger instead of bigint > -- > > Key: OPENJPA-2648 > URL: https://issues.apache.org/jira/browse/OPENJPA-2648 > Project: OpenJPA > Issue Type: Bug >Affects Versions: 2.4.1 > Environment: Windows 7 > Java 1.8.0_65 >Reporter: Bruno >Assignee: Mark Struberg >Priority: Blocker > > I've got an entity with Long as @Id. > OpenJPA creates database in a hsqldb environment. > The query that created table is : create table toto id integer identity. > It should be create table toto id bigint identity. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2859) [HSQLDB] HSQLDictionary wrongly maps double to NUMERIC without precision
[
https://issues.apache.org/jira/browse/OPENJPA-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved OPENJPA-2859.
Resolution: Fixed
> [HSQLDB] HSQLDictionary wrongly maps double to NUMERIC without precision
>
>
> Key: OPENJPA-2859
> URL: https://issues.apache.org/jira/browse/OPENJPA-2859
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 3.1.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.1.3
>
>
> Right now we create a {{NUMERIC}} field without any precision digits for
> double fields. This results in zero decimal fractions, which is clearly wrong.
> We should rather use DOUBLE SQL type, which is a 64bit 'aprox' type. If
> someone wants to use a fixed prec+scale then use {{BigDecimal}} which will be
> mapped as {{DECIMAL(n,m)}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OPENJPA-2859) [HSQLDB] HSQLDictionary wrongly maps double to NUMERIC without precision
[
https://issues.apache.org/jira/browse/OPENJPA-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg updated OPENJPA-2859:
---
Summary: [HSQLDB] HSQLDictionary wrongly maps double to NUMERIC without
precision (was: [HSQLDB] HSQLDictionary wrongly maps double to NUMBER without
precision)
> [HSQLDB] HSQLDictionary wrongly maps double to NUMERIC without precision
>
>
> Key: OPENJPA-2859
> URL: https://issues.apache.org/jira/browse/OPENJPA-2859
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 3.1.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.1.3
>
>
> Right now we create a {{NUMERIC}} field without any precision digits for
> double fields. This results in zero decimal fractions, which is clearly wrong.
> We should rather use DOUBLE SQL type, which is a 64bit 'aprox' type. If
> someone wants to use a fixed prec+scale then use {{BigDecimal}} which will be
> mapped as {{DECIMAL(n,m)}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OPENJPA-2859) [HSQLDB] HSQLDictionary wrongly maps double to NUMBER without precision
Mark Struberg created OPENJPA-2859:
--
Summary: [HSQLDB] HSQLDictionary wrongly maps double to NUMBER
without precision
Key: OPENJPA-2859
URL: https://issues.apache.org/jira/browse/OPENJPA-2859
Project: OpenJPA
Issue Type: Bug
Components: jdbc
Affects Versions: 3.1.2
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 3.1.3
Right now we create a {{NUMERIC}} field without any precision digits for double
fields. This results in zero decimal fractions, which is clearly wrong.
We should rather use DOUBLE SQL type, which is a 64bit 'aprox' type. If someone
wants to use a fixed prec+scale then use {{BigDecimal}} which will be mapped as
{{DECIMAL(n,m)}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OPENJPA-345) "openjpa" maven module has unnecessary dependencies on other openjpa modules
[ https://issues.apache.org/jira/browse/OPENJPA-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-345. --- Resolution: Fixed resolved ages ago > "openjpa" maven module has unnecessary dependencies on other openjpa modules > > > Key: OPENJPA-345 > URL: https://issues.apache.org/jira/browse/OPENJPA-345 > Project: OpenJPA > Issue Type: Bug > Components: build / infrastructure >Affects Versions: 0.9.0, 0.9.6, 0.9.7, 1.0.0 >Reporter: Marc Prud'hommeaux >Priority: Minor > Attachments: openjpa-345-trunk.patch > > > The "openjpa" module of the maven project (e.g., the one available from > http://www.ibiblio.org/maven2/org/apache/openjpa/openjpa/1.0.0/ ) is an > aggregate jar of all the other openjpa modules. For build reasons, this > module has a dependency on all the other openjpa modules. However, the > practical consequence is that when another project has a dependency on > "openjpa", jars from all the other modules are downloaded and added as > dependencies. So rather than just downloading the one "openjpa-1.0.0.jar" > that is needed, the following additional jars are also downloaded and added > as transitive dependencies of the maven project: > openjpa-jdbc-1.0.0.jar > openjpa-jdbc-5-1.0.0.jar > openjpa-kernel-1.0.0.jar > openjpa-kernel-5-1.0.0.jar > openjpa-lib-1.0.0.jar > openjpa-persistence-1.0.0.jar > openjpa-persistence-jdbc-1.0.0.jar > openjpa-xmlstore-1.0.0.jar > One solution might be to change the dependency type in the "openjpa" module > to be "system", but we would need to investigate the consequences of doing > this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2858) update dbcp2 to 2.8.0
[ https://issues.apache.org/jira/browse/OPENJPA-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-2858. Resolution: Fixed > update dbcp2 to 2.8.0 > - > > Key: OPENJPA-2858 > URL: https://issues.apache.org/jira/browse/OPENJPA-2858 > Project: OpenJPA > Issue Type: Bug > Components: build / infrastructure >Affects Versions: 3.1.2 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 3.1.3 > > > update dbcp2 to 2.8.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2858) update dbcp2 to 2.8.0
Mark Struberg created OPENJPA-2858: -- Summary: update dbcp2 to 2.8.0 Key: OPENJPA-2858 URL: https://issues.apache.org/jira/browse/OPENJPA-2858 Project: OpenJPA Issue Type: Bug Components: build / infrastructure Affects Versions: 3.1.2 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 3.1.3 update dbcp2 to 2.8.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2857) [MariaDB] locking in some cases gets handled via sqlState 70100
[
https://issues.apache.org/jira/browse/OPENJPA-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved OPENJPA-2857.
Resolution: Fixed
> [MariaDB] locking in some cases gets handled via sqlState 70100
> ---
>
> Key: OPENJPA-2857
> URL: https://issues.apache.org/jira/browse/OPENJPA-2857
> Project: OpenJPA
> Issue Type: Bug
>Affects Versions: 3.1.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.1.3
>
>
> [MariaDB] locking in some cases gets handled via sqlState 70100. This should
> be Treated as
> {color:#00}{{QueryTimeoutException}}{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2856) [MariaDB] improve TIME handling
[ https://issues.apache.org/jira/browse/OPENJPA-2856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-2856. Resolution: Fixed > [MariaDB] improve TIME handling > --- > > Key: OPENJPA-2856 > URL: https://issues.apache.org/jira/browse/OPENJPA-2856 > Project: OpenJPA > Issue Type: Bug > Components: jdbc >Affects Versions: 3.1.2 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 3.1.3 > > > It seems that MariaDB > 10 supports fractionDigits also for TIME columns > (although it doesn't show it in selects by default). > The other glitch we need to fix is that passing a java.sql.Time parameter > which got converted from a java.util.Date does not get properly matched > inside the database if the date part of the time internally is not Jan 1st > 1970. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2856) [MariaDB] improve TIME handling
Mark Struberg created OPENJPA-2856: -- Summary: [MariaDB] improve TIME handling Key: OPENJPA-2856 URL: https://issues.apache.org/jira/browse/OPENJPA-2856 Project: OpenJPA Issue Type: Bug Components: jdbc Affects Versions: 3.1.2 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 3.1.3 It seems that MariaDB > 10 supports fractionDigits also for TIME columns (although it doesn't show it in selects by default). The other glitch we need to fix is that passing a java.sql.Time parameter which got converted from a java.util.Date does not get properly matched inside the database if the date part of the time internally is not Jan 1st 1970. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2851) argument CURRENT_DATE cannot handle java.time.LocalDateTime entity fields
[ https://issues.apache.org/jira/browse/OPENJPA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-2851. Fix Version/s: 3.1.3 Resolution: Fixed Hi Karl, please test with the latest snapshot! > argument CURRENT_DATE cannot handle java.time.LocalDateTime entity fields > - > > Key: OPENJPA-2851 > URL: https://issues.apache.org/jira/browse/OPENJPA-2851 > Project: OpenJPA > Issue Type: Bug > Components: jpa >Affects Versions: 3.1.2 > Environment: h2 database >Reporter: Karl Grosse >Assignee: Mark Struberg >Priority: Major > Fix For: 3.1.3 > > > Using CURRENT_DATE as argument in queries for LocalDateTimeFields yields a > org.apache.openjpa.persistence.ArgumentException: Attempt to compare > incompatible types "class java.time.LocalDateTime" and "class java.util.Date". > > Field in entity: > @NotNull > @Column(name = "USEDUNTIL", nullable = false) > private LocalDateTime usedUntil; > Example Query: > @NamedQuery(name = QUERY_COUNT_BY_IDS, > query = "SELECT COUNT(t) FROM Dokumente t WHERE t.dokumentId IN :dokumentId > AND t.usedUntil >= CURRENT_DATE") > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OPENJPA-2851) argument CURRENT_DATE cannot handle java.time.LocalDateTime entity fields
[ https://issues.apache.org/jira/browse/OPENJPA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned OPENJPA-2851: -- Assignee: Mark Struberg > argument CURRENT_DATE cannot handle java.time.LocalDateTime entity fields > - > > Key: OPENJPA-2851 > URL: https://issues.apache.org/jira/browse/OPENJPA-2851 > Project: OpenJPA > Issue Type: Bug > Components: jpa >Affects Versions: 3.1.2 > Environment: h2 database >Reporter: Karl Grosse >Assignee: Mark Struberg >Priority: Major > > Using CURRENT_DATE as argument in queries for LocalDateTimeFields yields a > org.apache.openjpa.persistence.ArgumentException: Attempt to compare > incompatible types "class java.time.LocalDateTime" and "class java.util.Date". > > Field in entity: > @NotNull > @Column(name = "USEDUNTIL", nullable = false) > private LocalDateTime usedUntil; > Example Query: > @NamedQuery(name = QUERY_COUNT_BY_IDS, > query = "SELECT COUNT(t) FROM Dokumente t WHERE t.dokumentId IN :dokumentId > AND t.usedUntil >= CURRENT_DATE") > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OPENJPA-2855) primary keys do no respect naming rules
[ https://issues.apache.org/jira/browse/OPENJPA-2855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated OPENJPA-2855: --- Description: Seems we broke primary key column naming when adding support for HerdDB. https://github.com/apache/openjpa/commit/dd9bce0cc909bd96d706a9438bdc2a58111c481f#r49002420 Now all PK are delimited, which is not always what people want. Likely an unwanted side effect. was: Seems we broke primary key column naming when adding support for HerdDB. Now all PK are delimited, which is not always what people want. Likely an unwanted side effect. > primary keys do no respect naming rules > > > Key: OPENJPA-2855 > URL: https://issues.apache.org/jira/browse/OPENJPA-2855 > Project: OpenJPA > Issue Type: Bug >Affects Versions: 3.1.3 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 3.1.3 > > > Seems we broke primary key column naming when adding support for HerdDB. > https://github.com/apache/openjpa/commit/dd9bce0cc909bd96d706a9438bdc2a58111c481f#r49002420 > Now all PK are delimited, which is not always what people want. Likely an > unwanted side effect. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OPENJPA-2855) primary keys do no respect naming rules
Mark Struberg created OPENJPA-2855: -- Summary: primary keys do no respect naming rules Key: OPENJPA-2855 URL: https://issues.apache.org/jira/browse/OPENJPA-2855 Project: OpenJPA Issue Type: Bug Affects Versions: 3.1.3 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 3.1.3 Seems we broke primary key column naming when adding support for HerdDB. Now all PK are delimited, which is not always what people want. Likely an unwanted side effect. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2854) fix OffsetTime handling for PostgreSQL
[
https://issues.apache.org/jira/browse/OPENJPA-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved OPENJPA-2854.
Resolution: Fixed
> fix OffsetTime handling for PostgreSQL
> --
>
> Key: OPENJPA-2854
> URL: https://issues.apache.org/jira/browse/OPENJPA-2854
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 3.1.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.1.3
>
>
> PostgreSQL doesn't natively support OffsetTime. While it has a column type
> {{time with time zone}} it actually only stores the time as UTC time.
> On the JDBC level we need to use {{java.sql.Time}} with the servers local
> offset. The rest will be converted automatically inside the JDBC driver.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OPENJPA-2854) fix OffsetTime handling for PostgreSQL
Mark Struberg created OPENJPA-2854:
--
Summary: fix OffsetTime handling for PostgreSQL
Key: OPENJPA-2854
URL: https://issues.apache.org/jira/browse/OPENJPA-2854
Project: OpenJPA
Issue Type: Bug
Components: jdbc
Affects Versions: 3.1.2
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 3.1.3
PostgreSQL doesn't natively support OffsetTime. While it has a column type
{{time with time zone}} it actually only stores the time as UTC time.
On the JDBC level we need to use {{java.sql.Time}} with the servers local
offset. The rest will be converted automatically inside the JDBC driver.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2712) [JPA-2.2] add @Repeatable support for various annotations
[ https://issues.apache.org/jira/browse/OPENJPA-2712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved OPENJPA-2712. Fix Version/s: (was: 3.1.3) 3.1.2 Resolution: Fixed This has been resolved a while back already > [JPA-2.2] add @Repeatable support for various annotations > - > > Key: OPENJPA-2712 > URL: https://issues.apache.org/jira/browse/OPENJPA-2712 > Project: OpenJPA > Issue Type: Sub-task > Components: jpa >Affects Versions: 3.0.0 >Reporter: Mark Struberg >Priority: Major > Fix For: 3.1.2 > > > - https://github.com/javaee/jpa-spec/issues/115 > - extended existing annotations > - added new container annotations: javax.persistence.SequenceGenerators and > javax.persistence.TableGenerators -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OPENJPA-85) Update reserved words in DBDictionaries
[ https://issues.apache.org/jira/browse/OPENJPA-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned OPENJPA-85: Assignee: Mark Struberg > Update reserved words in DBDictionaries > --- > > Key: OPENJPA-85 > URL: https://issues.apache.org/jira/browse/OPENJPA-85 > Project: OpenJPA > Issue Type: Improvement > Components: sql >Reporter: Roger Keays >Assignee: Mark Struberg >Priority: Major > > It seems many of the DBDictionaries are a bit out of date WRT what reserved > words they define. The mysql dictionary, for example, only has 22 of the ~210 > reserved words in mysql > (http://dev.mysql.com/doc/refman/5.1/en/reserved-words.html). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (OPENJPA-2853) [MSSQL Server] support sendTimeAsDatetime handling
[
https://issues.apache.org/jira/browse/OPENJPA-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved OPENJPA-2853.
Resolution: Fixed
Yikes, took the wrong number in the commit. It is fixed here:
https://gitbox.apache.org/repos/asf?p=openjpa.git;a=commit;h=e9f3f9cdfcbb6479e02a477730debb320e5e5dbe
> [MSSQL Server] support sendTimeAsDatetime handling
> --
>
> Key: OPENJPA-2853
> URL: https://issues.apache.org/jira/browse/OPENJPA-2853
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
>Affects Versions: 3.1.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.1.3
>
>
> Microsoft SQL Server handles Time values in 2 different ways.
> [https://docs.microsoft.com/en-us/sql/connect/jdbc/configuring-how-java-sql-time-values-are-sent-to-the-server?view=sql-server-ver15]
> One way to make the SQLServer JDBC driver understand {{java.sql.Time}} is to
> add
> Depending on the configuration one can now enable {{sendTimeAsString}} in the
> {{SQLServerDictionary}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OPENJPA-2853) [MSSQL Server] support sendTimeAsDatetime handling
[
https://issues.apache.org/jira/browse/OPENJPA-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg updated OPENJPA-2853:
---
Description:
Microsoft SQL Server handles Time values in 2 different ways.
[https://docs.microsoft.com/en-us/sql/connect/jdbc/configuring-how-java-sql-time-values-are-sent-to-the-server?view=sql-server-ver15]
One way to make the SQLServer JDBC driver understand {{java.sql.Time}} is to add
Depending on the configuration one can now enable {{sendTimeAsString}} in the
{{SQLServerDictionary}}
was:
Microsoft SQL Server handles Time values in 2 different ways.
[https://docs.microsoft.com/en-us/sql/connect/jdbc/configuring-how-java-sql-time-values-are-sent-to-the-server?view=sql-server-ver15]
One way to make the SQLServer JDBC driver understand {{java.sql.Time}} is to add
Depending on the configuration one can now enable sendTimeAsString in the
{{SQLServerDictionary}}
> [MSSQL Server] support sendTimeAsDatetime handling
> --
>
> Key: OPENJPA-2853
> URL: https://issues.apache.org/jira/browse/OPENJPA-2853
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
>Affects Versions: 3.1.2
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 3.1.3
>
>
> Microsoft SQL Server handles Time values in 2 different ways.
> [https://docs.microsoft.com/en-us/sql/connect/jdbc/configuring-how-java-sql-time-values-are-sent-to-the-server?view=sql-server-ver15]
> One way to make the SQLServer JDBC driver understand {{java.sql.Time}} is to
> add
> Depending on the configuration one can now enable {{sendTimeAsString}} in the
> {{SQLServerDictionary}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
