Skip to main content

Bug Tracker

Side navigation

#8305 closed feature (worksforme)

Opened February 17, 2011 10:38PM UTC

Closed February 19, 2011 02:31AM UTC

Last modified March 14, 2012 07:48PM UTC

AJAX cache parameter breaks when calling Oracle procedure

Reported by: jsumners Owned by:
Priority: low Milestone: 1.next
Component: ajax Version: 1.5
Keywords: Cc:
Blocked by: Blocking:
Description

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.

Attachments (0)
Change History (6)

Changed February 17, 2011 10:44PM UTC by jsumners comment:1

Changed February 19, 2011 02:31AM UTC by jitter comment:2

component: unfiledajax
priority: undecidedlow
resolution: → worksforme
status: newclosed
type: bugfeature

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)

Changed February 19, 2011 02:42AM UTC by jsumners comment:3

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.

Changed February 19, 2011 09:59AM UTC by jitter comment:4

Replying to [comment:3 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, ...

Changed February 19, 2011 04:27PM UTC by jsumners comment:5

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?

Changed May 14, 2011 07:53PM UTC by jaubourg comment:6

#9275 is a duplicate of this ticket.