Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    InSet

    How to create a server-side InSet operator? I am doing the following:

    Code:
    DSRequest updateReq = new DSRequest("myDS"DataSource.OP_UPDATE, rpcManager);
    
    List<Criterion> criterions = new ArrayList<>();
    
    Criterion c = new SimpleCriterion("f_einrichtung", DefaultOperators.InSet, einrichtungen);
    criterions.add(c);
    
    updateReq.setAllowMultiUpdate(true);
    
    Map<String, Object> clearedValues = new HashMap<>();
    clearedValues.put("f_value_to_clear", null);
    updateReq.setValues(clearedValues);
    
    AdvancedCriteria ac = new AdvancedCriteria(DefaultOperators.Or, criterions.toArray(new Criterion[] {}));
    updateReq.setAdvancedCriteria(ac);
    
    updateReq.execute();
    But I am getting:
    RPCManager:com.isomorphic.criteria.criterion.SimpleCriterion cannot be cast to com.isomorphic.criteria.criterion.SetCriterion

    Code:
    17:21:14.500 [ERROR] [builtinds] 17:21:14.499:XRP2:WARN:RPCManager:com.isomorphic.criteria.criterion.SimpleCriterion cannot be cast to com.isomorphic.criteria.criterion.SetCriterion - response: {operationId: "custom", clientContext: undef, internalClientContext: undef, context: Obj, transactionNum: 0, httpResponseCode: 200, httpResponseText: "//isc_RPCResponseStart-->[{affectedRows:..."[250], xmlHttpRequest: [object XMLHttpRequest], transport: "xmlHttpRequest", status: -1, clientOnly: undef, httpHeaders: Obj, isStructured: true, callbackArgs: null, results: Obj, affectedRows: 0, data: "com.isomorphic.criteria.criterion.Simple..."[114], invalidateCache: false, isDSResponse: true, queueStatus: -1}
    com.smartgwt.client.core.JsObject$SGWT_WARN: 17:21:14.499:XRP2:WARN:RPCManager:com.isomorphic.criteria.criterion.SimpleCriterion cannot be cast to com.isomorphic.criteria.criterion.SetCriterion - response: {operationId: "custom", clientContext: undef, internalClientContext: undef, context: Obj, transactionNum: 0, httpResponseCode: 200, httpResponseText: "//isc_RPCResponseStart-->[{affectedRows:..."[250], xmlHttpRequest: [object XMLHttpRequest], transport: "xmlHttpRequest", status: -1, clientOnly: undef, httpHeaders: Obj, isStructured: true, callbackArgs: null, results: Obj, affectedRows: 0, data: "com.isomorphic.criteria.criterion.Simple..."[114], invalidateCache: false, isDSResponse: true, queueStatus: -1}
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
        at com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:105)
        at com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java:72)
        at com.google.gwt.dev.shell.OophmSessionHandler.invoke(OophmSessionHandler.java:172)
        at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:296)
        at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:551)
        at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:368)
        at java.lang.Thread.run(Thread.java:745)
    What am I doing wrong?
    Using smartgwt 6.1p power 6.1-p20180208

    #2
    Is there some reason you are trying to use SimpleCriterion instead of the dedicated SetCriterion? This is what SetCriterion is for.

    Comment


      #3
      Hi Isomorphic

      yes, I previously tried with SetCriterion but something is not working, maybe I am making an error somewhere.

      This is my testcase:

      It relies on the following table:
      Code:
      create table minimalTestcase
      (f_id int identity(1,1) primary key,
      f_lastname varchar(50) null,
      f_firstname varchar(50) null
      );
      
      insert into minimalTestcase (f_lastname, f_firstname) values ('A', 'X');
      insert into minimalTestcase (f_lastname, f_firstname) values ('B', 'Y');
      insert into minimalTestcase (f_lastname, f_firstname) values ('C', 'Z');
      and the following minimalTestcase.ds.xml:
      Code:
      <DataSource ID="minimalTestcase" serverType="sql" tableName="minimalTestcase">
      <fields>
         <field name="f_id" type="integer" primaryKey="true" />
         <field name="f_lastname" type="text" />
         <field name="f_firstname" type="text" />
      </fields>
      </DataSource>
      My server-side code:
      Code:
      public DSResponse doCallServer(DSRequest dsRequest, HttpServletResponse servletResponse, RPCManager rpcManager)
                  throws Exception {
      
              System.out.println("doCallServer");
      
              DSRequest updateReq = new DSRequest("minimalTestcase", DataSource.OP_UPDATE, rpcManager);
              List<Criterion> criterions = new ArrayList<>();
      
              Set<Long> pks = new HashSet() {
                  {
                      add(1);
                      add(2);
                  }
              };
              Criterion c = new SetCriterion("f_id", DefaultOperators.Equals, pks);
              criterions.add(c);
      
              updateReq.setAllowMultiUpdate(true);
      
              Map<String, Object> clearedValues = new HashMap<>();
              clearedValues.put("f_firstname", null);
              updateReq.setValues(clearedValues);
      
              AdvancedCriteria ac = new AdvancedCriteria(DefaultOperators.Or, criterions.toArray(new Criterion[] {}));
              updateReq.setAdvancedCriteria(ac);
      
              updateReq.execute();
      
              return new DSResponse();
          }
      But I get:
      Code:
      UPDATE minimalTestcase SET f_firstname=NULL WHERE '1'='1'
      What am I doing wrong?

      Comment


        #4
        Can you try both this and your other thread today with a more recent build? We do not seem to be replicating your results, and there were changes here to introduce the multiUpdatePolicy.

        Comment


          #5
          Hi Isomorphic

          same results with this build: 2018-03-22.

          Comment


            #6
            Hi,

            is this line really correct? Not at a computer now but IMHO it should be inSet:
            Criterion c = new SetCriterion("f_id", DefaultOperators.Equals, pks); Best regards Blama

            Comment


              #7
              Hi Blama
              thank you! As I said, I was not sure if I was not doing something wrong. With Criterion c = new SetCriterion("f_id", DefaultOperators.InSet, pks); the correct sql is being generated.

              Comment


                #8
                What I don't quite understand is why a repetition of the "inSet" is needed here:
                Criterion c = new SetCriterion("f_id", DefaultOperators.InSet, pks);

                1. SetCriterion
                2. DefaultOperators.InSet

                Isn't a SetCriterion always used with a DefaultOperators.InSet ? If yes, why is this parameter needed ? If no, in which cases can you use another operator together with a SetCriterion?

                As I said, with DefaultOperators.Equals this SQL is being generated:
                UPDATE minimalTestcase SET f_firstname=NULL WHERE '1'='1'
                Is it correct to generate this sql updating the whole table when using the "wrong" operator ? See my other thread on this: https://forums.smartclient.com/forum...lowmultiupdate
                Last edited by edulid; 25 Mar 2018, 23:37.

                Comment


                  #9
                  Both approaches are correct and data wise will produce same result as documented here, but first option from below is more accurate:
                  #1 InSet operator in combination with DefaultOperators.InSet will produce "field_name IN (value1, value2...)" SQL.
                  #2 InSet operator in combination with DefaultOperators.Equals will produce "field_name = value1 OR field_name = value2" SQL.

                  Note, that these differences in generated SQL are not documented in any way and are not guaranteed to stay like this in the future.

                  And yes, the #2 approach (InSet + Equals) had a bug, which is now fixed and will be available for download in nightly builds since March 27 (tomorrow).

                  Comment


                    #10
                    Thank you for the explanation and the bugfix!

                    Comment


                      #11
                      Hi Isomorphic

                      the builds from 27-03 are still creating:
                      UPDATE minimalTestcase SET f_firstname=NULL WHERE '1'='1'
                      in the #2 case: InSet operator in combination with DefaultOperators.Equals

                      Comment


                        #12
                        Please try again with 28-03 build. Most likely the fix did not make it into 27-03 build. Also, please make sure that your code uses the intended build exactly to exclude possible miss-dependency issues.
                        Last edited by Isomorphic; 28 Mar 2018, 02:52.

                        Comment


                          #13
                          This is working now, thanks!

                          Comment

                          Working...
                          X