Grid filter race condition

[Gucky]

When using the Grid Filter Feature, a query that is executed by the server may take about 10 seconds. Now it the user is typing a value into the filter field and waits more than the defined 500 milliseconds, before typing the next character, a second request will be send to the server, and again the user is slow in typing another one so we now have three request that have been send and will return in any order. Is there a way to ignore the first two and just take the last requests data? In my case as the last is the fastest, the data are returned only to be overwritten by the previous request that finally return a bit later. Any suggestions?

[tvanzoelen]

Is it the filter in the ux?

I see there the follwing method onStateChange,
mayby override it and do a check if the filter contains at least two characters before fire an filterupdate.

[Gucky]

Yes, its in ux, I could add that, but I need at least four to overcome the race condition, unfortunately I do need the ability to search from the first character onward.

[tvanzoelen]

Why is it needed to send the first characters to the server? The requests are made in the reload function

reload : function () {
        var me = this,
            store = me.view.getStore();

        if (me.local) {
            store.clearFilter(true);
            store.filterBy(me.getRecordFilter());
            store.sort();
        } else {
            me.deferredUpdate.cancel();
            if (store.buffered) {
                store.pageMap.clear();
            }
            store.loadPage(1);
        }
    }

Isn't it possible to condition that function that only three or four characters should be types before executing a reload?

[Gucky]

The problem is that the underlying table contains about 30000 records, the user needs to be able to get records starting with e.g. A or B and once displayed tighten the filter, Others may know the first 5 characters and will, as you suggest get a smaller list. But I am not able to enforce this. So ideally, the store should simply discard a request that is older than the one it already received. Hope this makes sense.

[tvanzoelen]

Well logically,

I think you should block a reload (clienside) if one is standing out. So disable mulitple loads, when one has not returned yet. You can put a listener on the store's load event to check when its finished. To check if the store is loading you can check isLoading function.

Meanwhile during that load you keep registering keystrokes, collect them, when the first load returns/stops you start executing the next filter request.


For that you need to modify the reload function of the filter plugin.

[Gucky]

I could do that, or it may be simpler to just fire on the Enter key rather than after each keystroke.

I still think that a feature , maybe for the store rather than the filter, to either
- only allow sequential calls therefore blocking any requests until the store is loaded
- have an option to discard an existing load is a new request comes in
would be useful.