ORDS version 24.1 is now available, time to upgrade!

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.

Run ‘ords config list –include-defaults’ to see all the ORDS configuration settings.

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.

You can still choose to land directly on any page/feature you want.

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:

If you’re looking in V$SQL or SQL Monitor and notice your query looks ‘funny,’ this is why.

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 –

This means anyone using this schema/login, will see the SQL ran as that database user.

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 🙂