Announcement

**Isomorphic** · 9 Dec 2013, 14:18

If you enable DEBUG-level logging for ResultSet, it will report the reasons why it is fetching data from the server. This will also show what row ranges are being request from ResultSet, which will help clarify if this is due to logic that is trying to look at rows that haven't been loaded, and this triggering fetches.

Also, Log.getStackTrace() generally provides better information than console.trace().

**yavery** · 10 Dec 2013, 08:18

Thanks for your reply.

I tried your suggested logging approach but it didn't quite work. Turning ON Debug
logging for ResultSet only, did not log anything in isc.showConsole(). What I also did
is turn ON Debug logging for fetchTrace, and I got some logging.

I did narrow things down to my second fetchData() being issued because I provide an
initialSort property on my ListGrid upon its creation ... If I remove that initialSort
property, the second unsolicited fetchData() goes away.

In both cases, fetching seem to be requested for rows 0-75 ... Here's what I obtained:

Code:

// requested fetchData()

 [a]MathFunction.getStackTrace(args=>undef, ignoreLevels=>undef, maxLevels=>undef, skipFBugTrace=>undef, extensionTrace=>undef)
    BaseDataSource.transformRequest(dsRequest=>Obj)
    DataSource.getServiceInputs(dsRequest=>Obj)
    DataSource.sendDSRequest(dsRequest=>Obj)
    DataSource.performDSOperation(operationType=>"fetch", data=>Obj, callback=>Obj, requestProperties=>Obj)
    DataSource.fetchData(criteria=>Obj, callback=>Obj, requestProperties=>Obj)
    ResultSet.fetchRemoteData(serverCriteria=>Obj, startRow=>0, endRow=>75)
    ResultSet._fetchRemoteData()
    ResultSet.getRangePaged(start=>0, end=>1, ignoreCache=>undef, fetchNow=>undef)
    ResultSet._getRangePaged(start=>0, end=>1, ignoreCache=>undef, fetchNow=>undef)
    ResultSet.getRange(start=>0, end=>1, ignoreCache=>undef, fetchNow=>undef)
    ListGrid.requestVisibleRows()
    Canvas.filterWithCriteria(criteria=>Obj, operation=>Obj{ID:dsAllowance_fetch}, context=>Obj)
    Canvas._filter(type=>"fetch", criteria=>Obj, callback=>afterFlowCallback(), requestProperties=>Obj)
    [a]MathFunction.invokeSuper(clazz=>null, methodName=>"_filter", a=>undef, b=>undef, c=>undef, d=>undef, e=>undef, f=>undef, g=>undef, h=>undef)
    [a]MathFunction.Super(methodName=>"_filter", args=>Array[4], nativeArguments=>[object Arguments])
    ListGrid._filter(type=>"fetch", criteria=>Obj, callback=>afterFlowCallback(), requestProperties=>Obj, doneSaving=>undef)
    Canvas.fetchData(criteria=>Obj, callback=>afterFlowCallback(), requestProperties=>Obj)
    BaseList.fetchData(criteria=>Obj, callback=>anonymous(), invalidateCache=>true)
    PromotionDetailViewManager.allowanceFetch()
    PromotionDetailViewManager.refreshUiCompleted()
    PromotionDetailViewManager.refreshUi(callSetActionButtonsState=>undef)
    PromotionDetailViewManager.createAndAddLayouts()
    createAndAddLayoutsObservation()
    BaseDetailViewManager.setupValuesManagers()
    callback(Obj, Array[1], Obj)
    [c]Class.fireCallback(callback=>callback(), argNames=>"dsResponse, data, dsRequest", args=>Array[3], target=>undef, catchErrors=>undef) on [Class Class]
    _dsCallback(dsResponse=>Obj, data=>Array[1], dsRequest=>Obj)
    ** recursed on [c]Class.fireCallback

// unsolicited fetchData() ... Seem to be induced by providing an initialSort upon creating ListGrid

    [a]MathFunction.getStackTrace(args=>undef, ignoreLevels=>undef, maxLevels=>undef, skipFBugTrace=>undef, extensionTrace=>undef)
    BaseDataSource.transformRequest(dsRequest=>Obj)
    DataSource.getServiceInputs(dsRequest=>Obj)
    DataSource.sendDSRequest(dsRequest=>Obj)
    DataSource.performDSOperation(operationType=>"fetch", data=>Obj, callback=>Obj, requestProperties=>Obj)
    DataSource.fetchData(criteria=>Obj, callback=>Obj, requestProperties=>Obj)
    ResultSet.fetchRemoteData(serverCriteria=>Obj, startRow=>0, endRow=>75)
    ResultSet._fetchRemoteData()
    [c]Class.fireCallback(callback=>"_fetchRemoteData", argNames=>undef, args=>Array[0], target=>[BaseResultSet ID:isc_BaseResultSet_1 (created by: isc_ListGrid_0)], catchErrors=>undef) on [Class ListGrid]
    [c]Class._fireActionsOnPause()
    ** recursed on [c]Class.fireCallback

Does this provide more/enough details as to how this could be resolved? I do need to
provide my initialSort property otherwise my listGrid header doesn't show the sorting
visual cue to the users, letting them know about how the list is currently being sorted.

Thanks,

**Isomorphic** · 10 Dec 2013, 10:38

We'll take a look and follow up when we have more information

Thanks
Isomorphic Software

**Isomorphic** · 13 Dec 2013, 14:27

Unfortunately we're not finding anything which is obviously responsible for this behavior.

From the stack traces, coupled with the intermittent nature of the issue, our guess is that this may be related to the ResultSet fetchDelay on your grid's data object.

We have an undocumented property - listGrid.dataFetchDelay - which governs this value and is set to 300 by default.
Can you experiment with adding dataFetchDelay:0 to your grid definition and see if this makes the problem go away for you?
If so there may be further work to do on our end for a reliable framework fix, but it will give us a good idea of where to look.

If this doesn't resolve it for you, we'll probably need a way to reproduce the problem.

As an aside - we've experimented with the 'initialSort' property and have had no success reproducing the problem with various tests.
Modifying the sort properties of a grid *after* the initial data fetch does indeed require a re-fetch (assuming data paging is enabled), but we're not seeing a pattern in which the "initialSort" attribute can cause this.

Sorry we don't have anything clearer to report at this stage. Please let us know how you get on with the dataFetchDelay attribute.

Regards
Isomorphic Software

**yavery** · 16 Dec 2013, 13:49

Hi,

I tried setting the dataFetchDelay to 0 and it had the opposite impact. Instead, I got many
many more fetch requests being issued. I also tried a higher value such as 2000 but I still get
that extraneous fetch request (only 1), same as with the default dataFetchDelay value (300).

Further investigation has revealed that this second fetch is issued because of a setViewState()
being issued on the listGrid as part of its construction process. When I comment out that
setViewState() call (and leave the initialSort property), I don't get that extraneous fetch.

Does this additional piece of information better help in identifying the root cause for this problem ?

Thanks,

**yavery** · 16 Dec 2013, 14:03

This is the data passed into setViewState():

Code:

({selected:"[]",field:"[{name:\"salesType\",width:37},{name:\"sellerDecoratedName\",width:180},{name:\"buyerDecoratedName\",width:180},{name:\"product_name\",width:254},{name:\"startDate\",width:80},{name:\"endDate\",width:80},{name:\"spendForecast\",width:72},{name:\"spendExpense\",width:72},{name:\"spendActual\",width:72},{name:\"fund_name\",width:66},{name:\"spendType\",width:98},{name:\"rateType\",width:68},{name:\"rate\",width:41},{name:\"performanceType_name\",width:112},{name:\"retailEventStartDate\",width:80},{name:\"retailEventEndDate\",width:80},{name:\"retailPromotedPrice\",width:8},{name:\"code\",width:56}]",sort:"({fieldName:\"salesType\",sortDir:\"ascending\",sortSpecifiers:[{property:\"salesType\",direction:\"ascending\",index:0,$78e:\"select\"}]})",hilite:null,group:""})

**Isomorphic** · 16 Dec 2013, 14:24

setViewState() that changes sortDirection (as this one does) would be expected to cause a new server fetch if the loaded data is large enough that sorting cannot be performed client-side.

Are able to reorder calls so that setViewState() is called before fetchData()? You would generally want to do this anyway.

**yavery** · 17 Dec 2013, 10:53

Hi,

I re-sequenced the setViewState() and the fetchData() calls but I still have
duplicated fetches to my backend ...

What I did to avoid the problem (which I don't find very elegant), is wrap my call
to fetchData() using a delayCall (without any delay, just to have it resequenced at
the end of the call chain). That seem to have removed the duplicate fetch.

Thanks,

**Isomorphic** · 17 Dec 2013, 12:49

That's not a great solution, but it will have to do unless you can create an isolated test case that shows that a framework issue is responsible, which we would then be able to fix.

Announcement

ListGrid fetchData issued twice (intermitent)

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment