[jira] [Commented] (OPENJPA-2668) CriteriaQuery instances should not change their state based on Query instances created from them
[ https://issues.apache.org/jira/browse/OPENJPA-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825185#comment-16825185 ] Michael Wiles commented on OPENJPA-2668: [pull request created|https://github.com/apache/openjpa/pull/41] > CriteriaQuery instances should not change their state based on Query > instances created from them > > > Key: OPENJPA-2668 > URL: https://issues.apache.org/jira/browse/OPENJPA-2668 > Project: OpenJPA > Issue Type: Bug > Components: jpa >Affects Versions: 2.4.1 >Reporter: Oliver Drotbohm >Assignee: Mark Struberg >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > JPA has a two-step, programatic query creation process: first, you create a > {{CriteriaQuery}} to build up the general query structure, add constraints on > it etc. Then you take that instance and create a {{(Typed)Query}} instance > from it using the currently available {{EntityManager}} and bind parameters > to it. > According to [reports we got for Spring Data > JPA|https://jira.spring.io/browse/DATAJPA-969], the latter step changes the > state of the {{CriteriaQuery}} instance, so that subsequent creations of > {{Query}} instances from it (and subsequent parameter bindings in turn) don't > actually get applied correctly. > Even if the subsequent creation and parameter binding got applied, that > change of state in {{CriteriaQuery}} instances is problematic in concurrent > access scenarios as the bindings might override each other partially. > Generally speaking I'd recommend to keep the {{CriteriaQuery}} instances > immutable with regards to the creation of {{Query}} instances from them and > the subsequent handling of those {{Query}} instances. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OPENJPA-2668) CriteriaQuery instances should not change their state based on Query instances created from them
[ https://issues.apache.org/jira/browse/OPENJPA-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817984#comment-16817984 ] Michael Wiles commented on OPENJPA-2668: added github project (reused an old one actually)... [https://github.com/michaelwiles/openjpa-spring-data-bug] with [test|https://github.com/michaelwiles/openjpa-spring-data-bug/blob/master/src/test/java/com/afrozaar/bug/openjpa/OpenJPA_2668_Test.java] > CriteriaQuery instances should not change their state based on Query > instances created from them > > > Key: OPENJPA-2668 > URL: https://issues.apache.org/jira/browse/OPENJPA-2668 > Project: OpenJPA > Issue Type: Bug > Components: jpa >Affects Versions: 2.4.1 >Reporter: Oliver Drotbohm >Assignee: Mark Struberg >Priority: Major > > JPA has a two-step, programatic query creation process: first, you create a > {{CriteriaQuery}} to build up the general query structure, add constraints on > it etc. Then you take that instance and create a {{(Typed)Query}} instance > from it using the currently available {{EntityManager}} and bind parameters > to it. > According to [reports we got for Spring Data > JPA|https://jira.spring.io/browse/DATAJPA-969], the latter step changes the > state of the {{CriteriaQuery}} instance, so that subsequent creations of > {{Query}} instances from it (and subsequent parameter bindings in turn) don't > actually get applied correctly. > Even if the subsequent creation and parameter binding got applied, that > change of state in {{CriteriaQuery}} instances is problematic in concurrent > access scenarios as the bindings might override each other partially. > Generally speaking I'd recommend to keep the {{CriteriaQuery}} instances > immutable with regards to the creation of {{Query}} instances from them and > the subsequent handling of those {{Query}} instances. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OPENJPA-2668) CriteriaQuery instances should not change their state based on Query instances created from them
[ https://issues.apache.org/jira/browse/OPENJPA-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817979#comment-16817979 ] Michael Wiles commented on OPENJPA-2668: So having had another go at this I've made some progress... The issue stems fundamentally from how the CriteriaQuery is cached by Spring Data and then it is changed when openjpa hydrates an "In" where clause. If you look at the code in [Expressions.java|https://github.com/apache/openjpa/blob/9f26ed29bf31b5c8ab68c5257d42e8c88765cf9b/openjpa-persistence/src/main/java/org/apache/openjpa/persistence/criteria/Expressions.java#L1436] you'll notice how the Expressions$In class modifies the _exps property. This property btw comes out of the CriteriaQuery so changes this class changes the CriteriaQuery. Now as far as I can make out, this is the only expression that is changing the CriteriaQuery. So I suspect if we simply clone the Expressions.In class and then operate on that one, it should work. So something like adding: {code:java} private Expressions.In copy() { In in = new Expressions.In<>(this.e); in._exps.addAll(this._exps); return in; } {code} And then after renaming the current toKernelExpression we make this method: {code:java} @Override org.apache.openjpa.kernel.exps.Expression toKernelExpression(ExpressionFactory factory, CriteriaQueryImpl q) { return copy().toKernelExpression0(factory, q); } {code} > CriteriaQuery instances should not change their state based on Query > instances created from them > > > Key: OPENJPA-2668 > URL: https://issues.apache.org/jira/browse/OPENJPA-2668 > Project: OpenJPA > Issue Type: Bug > Components: jpa >Affects Versions: 2.4.1 >Reporter: Oliver Drotbohm >Assignee: Mark Struberg >Priority: Major > > JPA has a two-step, programatic query creation process: first, you create a > {{CriteriaQuery}} to build up the general query structure, add constraints on > it etc. Then you take that instance and create a {{(Typed)Query}} instance > from it using the currently available {{EntityManager}} and bind parameters > to it. > According to [reports we got for Spring Data > JPA|https://jira.spring.io/browse/DATAJPA-969], the latter step changes the > state of the {{CriteriaQuery}} instance, so that subsequent creations of > {{Query}} instances from it (and subsequent parameter bindings in turn) don't > actually get applied correctly. > Even if the subsequent creation and parameter binding got applied, that > change of state in {{CriteriaQuery}} instances is problematic in concurrent > access scenarios as the bindings might override each other partially. > Generally speaking I'd recommend to keep the {{CriteriaQuery}} instances > immutable with regards to the creation of {{Query}} instances from them and > the subsequent handling of those {{Query}} instances. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OPENJPA-2668) CriteriaQuery instances should not change their state based on Query instances created from them
[ https://issues.apache.org/jira/browse/OPENJPA-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16538314#comment-16538314 ] Michael Wiles commented on OPENJPA-2668: Hi Mark... thanks for the input. I am keen to take up this issue as it seems we're at a stand still.. Please, if you don't mind, can you provide a little more detail if you can on what should be happening... i.e. the correct mechanism to do it with openjpa? > CriteriaQuery instances should not change their state based on Query > instances created from them > > > Key: OPENJPA-2668 > URL: https://issues.apache.org/jira/browse/OPENJPA-2668 > Project: OpenJPA > Issue Type: Bug > Components: jpa >Affects Versions: 2.4.1 >Reporter: Oliver Gierke >Assignee: Mark Struberg >Priority: Major > > JPA has a two-step, programatic query creation process: first, you create a > {{CriteriaQuery}} to build up the general query structure, add constraints on > it etc. Then you take that instance and create a {{(Typed)Query}} instance > from it using the currently available {{EntityManager}} and bind parameters > to it. > According to [reports we got for Spring Data > JPA|https://jira.spring.io/browse/DATAJPA-969], the latter step changes the > state of the {{CriteriaQuery}} instance, so that subsequent creations of > {{Query}} instances from it (and subsequent parameter bindings in turn) don't > actually get applied correctly. > Even if the subsequent creation and parameter binding got applied, that > change of state in {{CriteriaQuery}} instances is problematic in concurrent > access scenarios as the bindings might override each other partially. > Generally speaking I'd recommend to keep the {{CriteriaQuery}} instances > immutable with regards to the creation of {{Query}} instances from them and > the subsequent handling of those {{Query}} instances. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OPENJPA-2668) CriteriaQuery instances should not change their state based on Query instances created from them
[ https://issues.apache.org/jira/browse/OPENJPA-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15649120#comment-15649120 ] Mark Struberg commented on OPENJPA-2668: I did dig deeper into our source and the spec (6.5.10 Parameter Expressions). It seems that this behaviour might have even been intentionally. Please use CriteriaQuery.parameter to specify parameters whose value you gonna change later on. I verified that the resulting CriteriaQueries are perfectly reusable. > CriteriaQuery instances should not change their state based on Query > instances created from them > > > Key: OPENJPA-2668 > URL: https://issues.apache.org/jira/browse/OPENJPA-2668 > Project: OpenJPA > Issue Type: Bug > Components: jpa >Affects Versions: 2.4.1 >Reporter: Oliver Gierke >Assignee: Mark Struberg > > JPA has a two-step, programatic query creation process: first, you create a > {{CriteriaQuery}} to build up the general query structure, add constraints on > it etc. Then you take that instance and create a {{(Typed)Query}} instance > from it using the currently available {{EntityManager}} and bind parameters > to it. > According to [reports we got for Spring Data > JPA|https://jira.spring.io/browse/DATAJPA-969], the latter step changes the > state of the {{CriteriaQuery}} instance, so that subsequent creations of > {{Query}} instances from it (and subsequent parameter bindings in turn) don't > actually get applied correctly. > Even if the subsequent creation and parameter binding got applied, that > change of state in {{CriteriaQuery}} instances is problematic in concurrent > access scenarios as the bindings might override each other partially. > Generally speaking I'd recommend to keep the {{CriteriaQuery}} instances > immutable with regards to the creation of {{Query}} instances from them and > the subsequent handling of those {{Query}} instances. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OPENJPA-2668) CriteriaQuery instances should not change their state based on Query instances created from them
[ https://issues.apache.org/jira/browse/OPENJPA-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648926#comment-15648926 ] Mark Struberg commented on OPENJPA-2668: Most probably found the issue. We internally extrapolate the parameters already in the CriteriaQuery. So the TypedQuery will be constructed from the String "SELECT * FROM Department d WHERE d.name <> 'X'" with empty parameteres for example. But it really should be "SELECT * FROM Department d WHERE d.name <> ?" with 'X' as ParameterImpl(1, null, 'X'). > CriteriaQuery instances should not change their state based on Query > instances created from them > > > Key: OPENJPA-2668 > URL: https://issues.apache.org/jira/browse/OPENJPA-2668 > Project: OpenJPA > Issue Type: Bug > Components: jpa >Affects Versions: 2.4.1 >Reporter: Oliver Gierke >Assignee: Mark Struberg > > JPA has a two-step, programatic query creation process: first, you create a > {{CriteriaQuery}} to build up the general query structure, add constraints on > it etc. Then you take that instance and create a {{(Typed)Query}} instance > from it using the currently available {{EntityManager}} and bind parameters > to it. > According to [reports we got for Spring Data > JPA|https://jira.spring.io/browse/DATAJPA-969], the latter step changes the > state of the {{CriteriaQuery}} instance, so that subsequent creations of > {{Query}} instances from it (and subsequent parameter bindings in turn) don't > actually get applied correctly. > Even if the subsequent creation and parameter binding got applied, that > change of state in {{CriteriaQuery}} instances is problematic in concurrent > access scenarios as the bindings might override each other partially. > Generally speaking I'd recommend to keep the {{CriteriaQuery}} instances > immutable with regards to the creation of {{Query}} instances from them and > the subsequent handling of those {{Query}} instances. -- This message was sent by Atlassian JIRA (v6.3.4#6332)