Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.0
    • Fix Version/s: 2.0.0-M1, 2.0.0-M2
    • Component/s: kernel
    • Labels:
      None

      Description

      OpenJPAEntityManager oem = OpenJPAPersistence.cast(em);
      OpenJPAQuery query = oem.createQuery("openjpa.MethodQL", "de.logentis.openjpa.LogentisMethodQL.blabla");
      query.setResultClass(DP_PLZ_DA.class);
      query.setParameter(1, "Fred").setParameter(2, "Lucas");

      This results of an empty parameter Map in the LogentisMethodQL.blabla() method.

      Even worse, when doing parameter passing as stated in the docs Chapter 9 / 5:

      query.setParameter("first", "Fred").setParameter("last", "Lucas");

      There is an exception thrown.

      In fact MethodQL is completely broken when it comes to parameters at this point.

        Activity

        Hide
        Marc Logemann added a comment -

        Nice to have it also in 1.3.x

        Perhaps we should create a JIRA which makes the "declareParameters" obsolete. As discussed in the dev-list, we could determine the parameter types on the setParameter() calls on the public Query class. This would prevent users from calling (internal) delegates.

        Show
        Marc Logemann added a comment - Nice to have it also in 1.3.x Perhaps we should create a JIRA which makes the "declareParameters" obsolete. As discussed in the dev-list, we could determine the parameter types on the setParameter() calls on the public Query class. This would prevent users from calling (internal) delegates.
        Hide
        Donald Woods added a comment -

        Code checked into trunk as Rev750798 by Pinaki.
        Mike, can we also get this merged into 1.3.x?

        Show
        Donald Woods added a comment - Code checked into trunk as Rev750798 by Pinaki. Mike, can we also get this merged into 1.3.x?
        Hide
        Marc Logemann added a comment -

        The problem is somewhere in MethodStoreQuery.bindParameterTypes():

        private LinkedMap bindParameterTypes() {
        ctx.lock();
        try {
        if (_params != null)
        return _params;
        String params = ctx.getParameterDeclaration();
        if (params == null)
        return EMPTY_PARAMS;

        List decs = Filters.parseDeclaration(params, ',', "parameters");
        if (_params == null)
        _params = new LinkedMap((int) (decs.size() / 2 * 1.33 + 1));
        String name;
        Class cls;
        for (int i = 0; i < decs.size(); i += 2)

        { name = (String) decs.get(i); cls = ctx.classForName(name, null); if (cls == null) throw new UserException(_loc.get("bad-param-type", name)); _params.put(decs.get(i + 1), cls); }

        return _params;
        } finally

        { ctx.unlock(); }

        }

        _params is null and even ctx.getParameterDeclaration(); doesnt return anything useful. When passing the parameter into QueryImpl (the API one - not the delegate) it wont be passed in the lower layers (the delegate). This is at least what i ve learned from debugging so far.

        Show
        Marc Logemann added a comment - The problem is somewhere in MethodStoreQuery.bindParameterTypes(): private LinkedMap bindParameterTypes() { ctx.lock(); try { if (_params != null) return _params; String params = ctx.getParameterDeclaration(); if (params == null) return EMPTY_PARAMS; List decs = Filters.parseDeclaration(params, ',', "parameters"); if (_params == null) _params = new LinkedMap((int) (decs.size() / 2 * 1.33 + 1)); String name; Class cls; for (int i = 0; i < decs.size(); i += 2) { name = (String) decs.get(i); cls = ctx.classForName(name, null); if (cls == null) throw new UserException(_loc.get("bad-param-type", name)); _params.put(decs.get(i + 1), cls); } return _params; } finally { ctx.unlock(); } } _params is null and even ctx.getParameterDeclaration(); doesnt return anything useful. When passing the parameter into QueryImpl (the API one - not the delegate) it wont be passed in the lower layers (the delegate). This is at least what i ve learned from debugging so far.

          People

          • Assignee:
            Michael Dick
            Reporter:
            Marc Logemann
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development