Announcement

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

    Forcing a criteria change to result in a server fetch

    Hi Isomorphic,

    I have a DynamicForm I use as a filter editor for a ListGrid:
    Code:
    filterForm = new DynamicForm();
    SelectItemCampaign categorySI = new SelectItemCampaign("CAMPAIGN_ID");
    SelectItemLeadtype leadTypeSI = new SelectItemLeadtype("LEADTYPE_ID");
    SelectItemLeadtemperature leadTemperatureSI = new SelectItemLeadtemperature("LEADTEMPERATURE_ID");
    filterForm.setFields(categorySI, leadTypeSI, leadTemperatureSI);
    
    reloadButton = new IButton("Reload data");
    reloadButton.addClickHandler(new ClickHandler() {
    	@Override
    	public void onClick(ClickEvent event) {
    		resultGrid.fetchData(filterForm.getValuesAsCriteria());
    	}
    });
    
    resultGrid = new ListGrid(funnelDS);
    resultGrid.setFetchOperation("countLeads");
    resultGrid.setShowFilterEditor(false);
    resultGrid.setCanSort(false);
    resultGrid.setCanEdit(false);
    resultGrid.setCanAutoFitFields(false);
    resultGrid.setCanGroupBy(false);
    
    ListGridFieldLeadstatus leadstatusLFG = new ListGridFieldLeadstatus("Status", null);
    ListGridField count = new ListGridField("Count");
    resultGrid.setFields(leadstatusLFG, count);
    When I click the button 1st with no filter criteria, a fetch is issued. For every following criteria change, no fetch is issued and the ResultSet logs in the Developer Console:
    Code:
    16:53:37.684:MUP7:INFO:ResultSet:isc_ResultSet_4 (dataSource V_REPORTING_FUNNEL, created by: isc_ListGrid_0):setCriteria: filter criteria changed, performing local filtering
    I know for a fact that applying criteria will change the result, but the system thinks that it can satisfy the query from cache. I solved this by adding the following attribute to the DataSource tag in .ds.xml: "criteriaPolicy="dropOnChange", but I think this must not be necessary.

    This might be related to the operationBinding I'm using:
    Code:
    <operationBinding operationType="fetch" operationId="countLeads" outputs="STATUS_SHORTNAME, LEAD_COUNT">
    	<customFields>LEAD_COUNT</customFields>
    	<summaryFunctions>
    		<LEAD_COUNT>count</LEAD_COUNT>
    	</summaryFunctions>
    	<groupBy>STATUS_SHORTNAME</groupBy>
    </operationBinding>
    My question is if you know of any bugs in this area or if this expected behaviour?

    Also, what would be the client side-way of telling the ListGrid that it should do a server-hit for a fetchData(...)?

    I'm using latest 4.1p (v9.1p_2014-12-25).

    Best regards,
    Blama

    #2
    Hi Isomorphic,

    I searched the docs and found that this is not related to
    Code:
    resultGrid.fetchData(filterForm.getValuesAsCriteria(), null, new DSRequest() {
    	{
    		setShouldUseCache(false);
    	}
    });
    This shows a difference in the issued 1st request, but the following requests are served from cache nevertheless.

    It might be related to ResultSet.setUseClientFiltering(false):
    Code:
    resultGrid.fetchData(filterForm.getValuesAsCriteria(), null, new DSRequest() {
    	{
    		if (resultGrid.getResultSet() != null)
    			resultGrid.getResultSet().setUseClientFiltering(false);
    	}
    });
    sends a new request to the server every time.

    Shouldn't be there a convenience method ListGrid.setUseClientFiltering() as well?

    (This does not answer the question if the observed behaviour is expected.)

    Best regards,
    Blama

    Comment


      #3
      If criteria is unchanged there is no new request to the server - this is documented on fetchData() and elsewhere.

      Setting criteriaPolicy would not be a way of forcing a new request - see the documentation for this property - what it would actually do is cause a new fetch for changed criteria, even if the new criteria is determined to be more restrictive.

      shouldUseCache is also unrelated - see the docs for this property.

      If you are trying to force a refresh, you could either use the listGrid.refreshData() API, or make sure the criteria differ every time, such as by adding an additional criterion that has the current timestamp (new Date().getTime()).

      Finally, you can disable client filtering via listGrid.dataProperties with setUseClientFiltering:false. This definitely should not be a convenience method as most cases of wanting to disable this are misconceptions or coding errors.

      Comment


        #4
        Hello Isomorphic,

        as I said, the criteria change: "When I click the button 1st with no filter criteria, a fetch is issued. For every following criteria change, no fetch is issued".

        But as the client has the whole ResultSet, it thinks it can solve everything with client-side filtering.
        This is not the case as the filter-criteria don't even appear in the result, as this is a aggregation-query with an outputs-tag for the groupBy-field and the aggregated field.

        If needed I can try to generate a test case from BuiltInDS.

        Thanks for pointing me to ListGrid.dataProperties. For me, this is the convenience method I was looking for.

        Best regards,
        Blama

        Comment


          #5
          This too is covered in the docs for fetchData(). No need for a test case as this is documented and correct behavior.

          Comment


            #6
            Hi Isomorphic,

            you are referring to this sentence, correct?
            ListGrid.fetchData(): Changes to criteria may or may not result in a DSRequest to the server due to client-side filtering. You can call willFetchData(criteria) to determine if new criteria will result in a server fetch.

            I think that I have found a use case where this does not work as expected - or perhaps it does from the specification side, but it is not what I (or an other user) would expect.

            Best regards,
            Blama

            Comment


              #7
              In general, if the server doesn't return data sufficient for client-side filtering to work, client-side filtering will not work.

              There is no general-purpose way to detect that this has happened, and client-side filtering is definitely something we want on by default.

              Comment

              Working...
              X