#5125 closed enhancement (worksforme)
Ajax Caching doesn't work in PL/SQL web environment
Reported by: | shantydweller | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 1.4 |
Component: | ajax | Version: | 1.3.2 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
the cache:false statement does not work properly in PL/SQL Oracle 10g Web Server environments. This is because the _ querystring variable name being used to cache can never be a valid PL/SQL identifier.
Change History (4)
comment:1 Changed 13 years ago by
Component: | unfiled → ajax |
---|
comment:2 Changed 13 years ago by
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:3 Changed 12 years ago by
I came across this as well. I know you request a test case, but simply the $.ajax() function works as expected in generating the URL, but the '_=' in the query string is invalid syntax for PL/SQL. All PL/SQL identifiers must begin with a letter. The *client* in this instance doesn't ignore it.
OUTPUT URL: http://[hostname]/[dadname]/ajax_script.prc?_=2323876868688&p_id=1
ERROR: 400 Bad Request => "Bad name in request: not a legal PLSQL identifier..."
@shantydweller, only way around it currently is to manually add a "p_nocache=TIMESTAMP" to query string, as well as, add it to the requested stored procedure's IN parameters as well. Tedious, but it works.
comment:4 Changed 12 years ago by
This can be fixed with flexible paramter passing:
procedure ck(name_array owa.vc_arr, value_array owa.vc_arr) is begin
to_char(sysdate, 'hh:mi:ss')); |
end;
<script>
$.ajax({
url: '!ck', cache: false, success: function(data) {
alert(data);
}
});
</script>
Notice the ! in the url: !ck this will accept any number of url parameters. Flexible parameters are very nice. You can pass anything. I use flexible parameters for everything. Load the parameters into a associative array, and it's very easy:
url tool.urltype := tool.load(name_array,value_array);
Then to access a param just do: url('xyz')
That argument is there to tell the *client* not to use the cached request, so it will make a fresh one. It's okay for the server to ignore the cache busting argument, as long as it responds with data.
If there is something else going on, please reopen with more details about what the client sends and how the server responds. A trace with Fiddler or Wireshark might help.