AJAX cache parameter breaks when calling Oracle procedure

[jsumners]

This is really a duplicate of #5125, but that is closed and I can't reopen it.

When sending an AJAX request to an Oracle PL/SQL procedure the parameters in the URL _must_ match the procedure signature. However, you can not name a variable simply "_" in PL/SQL. Therefore, you either have to turn off jQuery's cache fix, and break the reason it is implemented, or do some other very annoying work around.

So it would be nice if you could specify a name for the cache parameter.

[jsumners]

 https://github.com/jquery/jquery/pull/236

[jitter]

Thanks for taking the time to contribute to the jQuery project by writing a feature request.

I don't think that having an option to give the cache parameter a custom name is a need for the broader part of the community. That combined with the amount of code your pull request would add makes for a bad cost/benefit factor.

Instead you can use a in jQuery 1.5 newly introduced functionality which allows you to easily customize your ajax calls.  A prefilter. Which could look like the following

$.ajaxPrefilter(function(options, originalOptions, jqXHR) {
    // when caching is disabled and the
    // custom oraclePLSQLCall option is set
    // use that as custom name for the anticache param
    if (!options.cache && options.oraclePLSQLCall) {
        options.cache = true;
        options.url += (/\?/.test(options.url) ? "&" : "?") + options.oraclePLSQLCall + "=" + jQuery.now();
    }
});

You can check this out in this  live test case (which actually includes an alternative prefilter approach)

[jsumners]

I believe you are going to find this catching more than a few people. Before 1.5 the cache option did not default to false for JSON requests. I am sure that I'm not the only one that will encounter this problem (e.g.  http://preview.tinyurl.com/47wth4r and the two reports in #5125).

I bet this bug will be filed more frequently now that 1.5 has changed expected behavior.

[jitter]

Replying to jsumners:

I believe you are going to find this catching more than a few people. Before 1.5 the cache option did not default to false for JSON requests. I am sure that I'm not the only one that will encounter this problem (e.g.  http://preview.tinyurl.com/47wth4r and the two reports in #5125).

I bet this bug will be filed more frequently now that 1.5 has changed expected behavior.

What behavior changed in 1.5? JSON requests don't default to false and never did so, as can be seen with this  test case

In jQuery 1.4x JSONP requests incorrectly defaulted to true for the cache option, which was a bug that got fixed. If you knew about that behavior you should have reported it. This  test case shows that in 1.4.x the anticache option is incorrectly missing from the requests.

---

It's also interesting that you don't give any feedback about the proposed solution. If it works for you, if you consider it a viable solution, ...

[jsumners]

What behavior changed? Pre 1.5 the following worked:

$.ajax({
  url: 'http://example.com/some/oracle.procedure',
  data: {onlyParam: 'value'},
  success: function(data){ console.log('yay! it works.'); }
});

After 1.5 that code will not work because the "_" parameter automatically gets added to the request. I see in the 1.4.x code where it was supposed to add "cache = false" to JSONP requests (sorry, forgot a P last post), but that wasn't in the documentation, from what I recall, and that isn't how it worked. So why would I have reported it if I didn't know it was behaving incorrectly and worked as I expected it to?

As for the proposed solution. I'm sure it works, but I won't be able to test it until Monday. But I can tell you that I don't particularly care for it. It would be easier to set "cache = false" for those interacting with Oracle. I think a user would be more likely to choose to rename the cache parameter if the library supported it, but would simply set "cache = true" otherwise. And isn't the jQuery moto "write less, do more"? Which solution allows the jQuery user to write less and do more?

[jaubourg]

#9275 is a duplicate of this ticket.