I won’t read the release notes for you, but I will summarize. Consider this your TL;DR summary!
Core ORDS
By ‘core ORDS’ – I mean the basic ‘guts’ of the Oracle REST Data Services software. One of changes is significant.
- Metadata Caching enabled by default with a default timeout of 1 second
This means heavy consumers of REST APIs, esp those of the AUTO variety, could see as much as 3x faster response times. That’s pretty cool. Note we’ve just changed the ‘DEFAULT’ behavior – you can always go into the config and turn this off, explicitely.
This means if you make a change to a REST API definition, it could take as long as 1 second for that definition to be updated/reflected in your environments.
This effectively means we run fewer SQLs internally to pull up the REST API and privilege definitions before running your APIs. Less work, means faster APIs. The more you hit the endpoints, the more benefit you will see. If you don’t see the benefit, you may want to increase the cache timeout period.
SQL Developer Web
New Home Page
No more generic list of index cards! Now you get a ‘recent’ or ‘pinned’ list of features on the ‘LauchPad,’ or you get a list of features by feature area, complete with descriptions, doc links, and screenshots to give you an idea of what’s possible.
Running SQL, w/o the paging
In the SQL Worksheet, there’s now a drop-down button when you want to execute a SQL statement.
Remember when I wrote that post, ‘How does paging work?‘ When you run SQL, we don’t just run that SQL, we wrap it with an Analytic Function – like so:
To support this on the backend, the REST Enabled SQL feature has also been enhanced, if you set the offSet to -1, it turns off paging. We also add a limit of 256 rows, so we don’t overwhelm your browser with query results.
SQL History has been moved from your browser to the database
Instead of storing your SQL History in your browser (using a browser based database), stored for each database user, for each database you login to, it will now be stored by SCHEMA in the database you’re logged in as.
If you’re using a ‘read only’ environment, the SQL History will default back to your browser.
You’ll see that data sourced here SCHEMA.DBTOOLS$EXECUTION_HISTORY –
IF you disable SQL History, it will nuke the data in the table, meaning anyone relying on the history for that database user account, will lose it. So if you’re sharing database logins, ‘be nice.’
There’s a lot more I could go over, but then this wouldn’t be a TL;DR summary 🙂
11 Comments
Update to Apex 24.1 upgrade issue – URL via Custom ORDS to Apex console not working.
Thought we had the problem identified, come to find out that the Apex 24.1 upgrade breaks customer managed ORDS.
From the Apex/ORDS team:
APEX 24.1 introduced APEX_PUBLIC_ROUTER user to support the new Friendly URLs architecture. On ADB-S, this setup works as expected with the Oracle-managed ORDS. However, the customer-managed ORDS does not work because the connection pool user (for example, ORDS_PUBLIC_USER2) cannot be configured to proxy into APEX_PUBLIC_ROUTER.
The issue here is on ORDS side, even when the break started with the APEX upgrade that means ORDS need to adjust and make sure you still can use “ORDS_PREHOOK” in the configuration files. We will sent the case to ORDS on Autonomous team so they can answer if this parameter is still valid or not and if it is, they may need to apply a workaround behind scenes to you can continue using it.
The fix is pretty simple but was a bear to diagnose and remediate.
1. Check the prehook function doesn’t use AuthID
2. Grant execute on the prehook function to ORDS_PUBLIC_USER2 (normal) and APEX_PUBLIC_ROUTER
This can impact anyone using customer managed ORDS upgrading Apex to 24.1, which is being applied in an automated mandatory function starting this weekend (in our region).
Putting this here to hopefully speed recovery if you hit this – it took over a week to diagnose with the help of both the Apex, ORDS, and Oracle Retail Applications teams.
Just a note, there were some bugs with ORDS 24.1/Apex 24.1 as well, so we upgraded that to the level on the ATP-S DB – 24.2.2 just to be safe.
ahhhh THIS
ok ok ok
it’s an apex bug, we’ve fixed it on the backend. if you’re using prehooks, yes you need to grant execute on your prehook program to APEX_PUBLIC_ROUTER. AND we have updated that information in our docs around the PREHOOK feature.
Hi Fellow Jeff,
We are running Apex 23 with customer managed ORDS 24.1 on Tomcat 9 against ATP DB in OCI.
I just did an upgrade of Apex to 24.1, can’t get to Apex console via Cust Ords, but can using public endpoint. Saw a potential bug notice so upgraded Cust Ords to 24.2.2 to match what’s on the ATP DB.
We are getting the “missing prehook” error when trying to get to …/ords/apex and to a couple of similar application (Oracle Retail) url’s. However, the connection to the DB is valid on the Cust Ords node and back-end use of ords for job submission is working. Only direct /ords/xxx access seems to throw the error.
The prehook error is a fun one to troubleshoot, but the only change to the stable system is the upgrades so wondered if you had an idea on this, or perhaps better, to a process to diagnose and repair prehook errors. (i.e. in our last upgrade, /ords would bring us to Apex console before, but after the last upgrade we had to use /ords/apex – was a hard one to diagnose) so an approach to diagnosis of this error would be a very beneficial process note.
Thanks for the help and for all you bring to an infrastructure plumber saddled with ORDS administration.
– Jeff B
I would need to see the actual error.
You can still have /ords redirect to apex, simply set the misc.defaultPage parameter to ‘apex’
You need to make sure ords_public_user, apex_public_user have execute privs on your your prehook, and that if you execute the function it returns a TRUE or FALSE, that’s about all the debug info I can provide, unless you want to share what you’re using the prehook function for?
The prehook was a call to Oracle Retail packaged code, so I have no idea what it is doing.
However, we found the issue – someone had blocked the return traffic from the DB to our internal load balancer, so the call was never being returned. So it was a network access error (security feature) leading to the prehook error message. We can get to the console via DB private endpoint so all is well.
The change was not communicated and had nothing to do with the upgrade – “just so happened” to be interesting timing.
Thanks for the help.
– Jeff
oh gosh…yeah, that would be a problem
Hi Jeff, just noticed that my schema now has DBTOOLS$EXECUTION_HISTORY which increased my backup size by 25MB
No big deal but how can I purge this history table.
I’m backing up my schema to Github and even with the compression option this might exceed Github 100MB limit.
It’s a table, you can truncate it or whatever you want – but you’ll lose your SQL History.
I would program your backup to OMIT that table completely, so you can have your cake and eat it.
Hi Jeff, is ORDS 24.1 compatible with APEX 23.2.6?
With ANY supported version of APEX, yes.