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

          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.
          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.
          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?
          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

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development