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 comment:1
Changed February 19, 2011 02:31AM UTC by comment:2
component: | unfiled → ajax |
---|---|
priority: | undecided → low |
resolution: | → worksforme |
status: | new → closed |
type: | bug → feature |
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 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 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 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?
https://github.com/jquery/jquery/pull/236