OpenJPA
  1. OpenJPA
  2. OPENJPA-1999

Optional support for non-sequential positional parameters

    Details

      Description

      Optional support for less strict following of positional parameters. e.g.

      Query query = entityManager.createQuery("SELECT m from Movie as m WHERE m.title = ?2 AND m.year = ?4");
      query.setParameter(2, "Foo");
      query.setParameter(4, 2011);
      return query.getResultList();

      Previous OpenJPA releases support this as do current EclipseLink and Hibernate versions. For the migration and upgrade scenarios and the development scenario – can be a pain to have to always update positional parameters while tweaking queries – this could make a compelling optional feature.

        Issue Links

          Activity

          David Blevins created issue -
          David Blevins made changes -
          Field Original Value New Value
          Link This issue relates to OPENJPA-1992 [ OPENJPA-1992 ]
          Hide
          Rick Curtis added a comment -

          @David -

          Please give the attached patch a try. I'll note that it's still a little fluid, but I'd like to get confirmation that it works for you before spending much more time going down this path.

          Since this behavior goes against the spec and it worked for one reason or another in a previous release, I'm not planning on enabling this functionality by default. To enable support for this feature, you'll have to set a new comparability flag[1].

          The gist of this patch is that I mapped all positional parameters to a stringified version of the param ($1=>:_1). This way the runtime thinks the user has named parameters and the user thinks they're using positional parameters.

          [1]openjpa.Compatibility=ConvertPositionalParametersToNamed=true

          Show
          Rick Curtis added a comment - @David - Please give the attached patch a try. I'll note that it's still a little fluid, but I'd like to get confirmation that it works for you before spending much more time going down this path. Since this behavior goes against the spec and it worked for one reason or another in a previous release, I'm not planning on enabling this functionality by default. To enable support for this feature, you'll have to set a new comparability flag [1] . The gist of this patch is that I mapped all positional parameters to a stringified version of the param ($1=>:_1). This way the runtime thinks the user has named parameters and the user thinks they're using positional parameters. [1] openjpa.Compatibility=ConvertPositionalParametersToNamed=true
          Rick Curtis made changes -
          Attachment OPENJPA-1999.patch [ 12480540 ]
          Rick Curtis made changes -
          Assignee Rick Curtis [ curtisr7 ]
          Rick Curtis made changes -
          Fix Version/s 2.2.0 [ 12315910 ]
          Hide
          Pinaki Poddar added a comment -

          The commit shows no tests with PreparedQuery. In a related thread, it had been discussed that a change of this nature may impact PreparedQuery.
          How about executing few of the queries with non-kosher binding parameter twice so that the second time the parameters get rebind?

          Show
          Pinaki Poddar added a comment - The commit shows no tests with PreparedQuery. In a related thread, it had been discussed that a change of this nature may impact PreparedQuery. How about executing few of the queries with non-kosher binding parameter twice so that the second time the parameters get rebind?
          Michael Dick made changes -
          Fix Version/s 2.1.1 [ 12316191 ]
          Rick Curtis made changes -
          Link This issue relates to OPENJPA-2029 [ OPENJPA-2029 ]
          Hide
          Rick Curtis added a comment -

          Resolving issue.

          I created OPENJPA-2029 to address Pinkai's testing concerns.

          Show
          Rick Curtis added a comment - Resolving issue. I created OPENJPA-2029 to address Pinkai's testing concerns.
          Rick Curtis made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          Albert Lee added a comment -

          Close issue in preparation for 2.2.0 release.

          Show
          Albert Lee added a comment - Close issue in preparation for 2.2.0 release.
          Albert Lee made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Resolved Resolved
          60d 23h 2m 1 Rick Curtis 13/Jul/11 16:16
          Resolved Resolved Closed Closed
          204d 52m 1 Albert Lee 02/Feb/12 17:09

            People

            • Assignee:
              Rick Curtis
              Reporter:
              David Blevins
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development