openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Work logged] (OPENJPA-2668) CriteriaQuery instances should not change their state based on Query instances created from them
Date Wed, 24 Apr 2019 12:02:00 GMT


ASF GitHub Bot logged work on OPENJPA-2668:

                Author: ASF GitHub Bot
            Created on: 24/Apr/19 12:01
            Start Date: 24/Apr/19 12:01
    Worklog Time Spent: 10m 
      Work Description: michaelwiles commented on pull request #41: OPENJPA-2668 fix for query
execution leaking into CriteriaQuery
   for [OPENJPA-2668](
   added copy method to Expressons.In and use that to return the expression
   so that the original is not changed.
   Not sure if there's a better way to do this. This is quite how can I say, simple?
   This is the only Expression that I could find that dirties the original CriteriaQuery and
I'm fairly convinced that this shouldn't happen.
   Prior to this fix, executing the test would change the query and replace the parameter
with the hydrated parameter values.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

Issue Time Tracking

    Worklog Id:     (was: 232035)
    Time Spent: 0.5h  (was: 20m)

> CriteriaQuery instances should not change their state based on Query instances created
from them
> ------------------------------------------------------------------------------------------------
>                 Key: OPENJPA-2668
>                 URL:
>             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|],
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

View raw message