Bypass all cacheing on jQuery.autocomplete(1.02)

Question

I am using jQuery.autocomplete(1.02) on my search box and I want exact string and substring matching. I don't care (yet!) about the database load, I'm happy for it to fire off a query every keystroke and bypass the caching entirely - I just don't want anything missed.

To this end I have tried setting cacheLength=1, the minimum permitted, but the autocomplete function refuses to fire off a GET request for each key up.

searchbox          GET_request

   'a'       ->    http://localhost/service_search_request?q=a
   'ar'      ->    http://localhost/service_search_request?q=ar
   'ars'     ->    http://localhost/service_search_request?q=ars

Instead, it sends the first and the third and misses the second, giving me the wrong results for 'ar' :-/ I've cleared my cache and sessions but it looks like some sort of caching is still going on. AFAIK I have no proxying going on and I'm shift-refreshing each time. It looks likely then that this behavior is from jQuery.autocomplete itself.

So my questions are...

A) Does this seem likely? i.e. is it a feature, or maybe a bug?

B) If so is there a clean way around it?...

C) If not, what autocomplete would you use instead?

Naturally D) No you're just using it incorrectly you douche! is always a possibility, and indeed the one I'd prefer having spent time going down this road - assuming it comes with a link to the docs I've failed to find / read!

Cheers,

Roger :)

Answer 1

I wonder why cacheLength doesn't work, but had trouble with autocomplete too. IMHO, there are errors in it. However, in the list of options, there is a matchSubset you could set to false.

EDIT: somewhere around line 335 is a function called "request". You could add some debug messages to it, to see what happens: (note: you need firebug installed or "console" will be unknown)

function request(term, success, failure) {

 console.debug("ac request...");

 if (!options.matchCase)
  term = term.toLowerCase();

 var data = cache.load(term);

 console.debug("ac request 1, loaded data from cache: " + data + " term: " + term);

 // recieve the cached data
 if (data && data.length) {
  success(term, data);
 // if an AJAX url has been supplied, try loading the data now
 } else if( (typeof options.url == "string") && (options.url.length > 0) ){

  console.debug("ac request 2, data is not in the cache, request it");

"flushCache" can easily be used in the function you can attach / set as options. I used this, to clear the Cache, if there could be more data in the backend:

formatItem: function (data,i,n,value){
    if(i === (this.max -1)){
        console.debug("flushCache");
        jQuery(this).flushCache();
    }

    return data[1] + " (" + data[0] + ")";
}

Answer 2

I am having the same problem. Caching doesn't work although I have set the option cacheLength to 1.

With your solution to call the flushCache function after each printed term it works. I couldn't use the:

if(i === (this.max -1)){

since 'i' was e.g 1 after filtering but 'this.max' still 25 as the original backend query resulted in 25 returned rows.

However, this bug ONLY appears when typing words that contain the swedish characters 'å', 'ä' or 'ö'. So maybe the cashing works as expected but not with these special characters.

Anyway. the solution for me was to always call the flushCache control in the formatItem() function:

function formatItem(row, position, n, term) {

    if($("#keywords-h").length > 0){
     $("#keywords-h").flushCache();
        }

        // format Item
        return "<span>" + row[0] + "</span>";
}

Hope this helps someone and if someone is having the same problems with special characters please post a reply.

Answer 3

Hi guys - I had exactly the same problem - cacheLength didn't make any difference no matter what I set it to, it would always be the default of 10. I repeatedly tried it on 1 because I didn't want any caching, but still came back with 10. I randomly tried setting it to 0 and it worked. crazy but true ;o)

Answer 4

Have obviously come to this 18 months on, but

cacheLength: 0

in the options worked for me. So maybe latest release has fixed the bug?