If you’re active in the Twitter-verse you will have seen a bunch of tweets yesterday about the release of the 18.1.x versions of Oracle REST Data Services (ORDS), SQL Developer (and Data Modeler) and SQLcl.
The first thing I did was edit my ORDS Docker build to use the latest versions of ORDS, SQLcl, Tomcat9 and Java9. If you are interested in playing with that you can find the build on my GitHub here. It was all smooth sailing! đŸ™‚
There are a couple of things I would like to point out about the ORDS 18.1 documentation.
ORDS Installation in Multitenant
The way I read it, the documentation suggests there are two ways of installing ORDS in a multitentant environment, both of which involve installing it into the CDB.
Multitenant is an architecture, so it doesn’t imply the presence of the Multitenant option, or multiple PDBs in the CDB. In fact, I would suggest the vast majority of CDBs will only ever contain a single PDB, as most instances will eventually switch to Lone-PDB (for free) now that non-CDB is deprecated. So what does this have to do with the installations described above?
The advantage of installing ORDS in the CDB is you can have a single connection pool for all PDBs in the instance, which is a big advantage if you have 4096 PDBs in your CDB. If you only have one PDB per CDB, there is no advantage, and actually there is a disadvantage because the PDB has yet another dependency on the CDB, which means ORDS must be installed in the other CDBs before you clone/relocate a PDB to them.
In my opinion, the best way to install ORDS for Lone-PDB, and possibly even for small numbers of PDBs in one instance, is to install directly into the PDB, just like we do with APEX. This means each PDB needs its own connection pool in ORDS, but that’s not a problem. This way the PDB doesn’t have an external ORDS dependency on the container and can be moved between containers without any fuss.
You will see my ORDS installation article installs directly into the PDB, although I will be amending it with some comments about other options.
Database Authentication for PL/SQL Gateway Calls
One of the new features of ORDS 18.1 is you can now use database authentication to provide basic authentication for your calls to PL/SQL. You won’t see that in the documentation though. It’s only present in the examples under the “/path/to/ords/examples/db_auth” directory when you unzip the ORDS media.
Using this type of authentication is not advisable, it’s much better to use OAuth2, but for people like me that have a lot of applications and XML web services still using mod_plsql, this is a really handy feature, and certainly eases the transition from mod_plsql to ORDS.
It would be nice if this feature were put into the main documentation, as it will be a welcome addition for many people out there. It is a feature, so it should be documented as such, and anything that improves the uptake of ORDS has got to be a good thing.
How’s about including the document upload/download functionality from mod_plsql in ORDS also? That would help with the transition too. Yes, I know it’s easy to code this yourself, but that is still an application change, rather than just switching from one gateway to another. Just sayin’. đŸ™‚
I’ll be playing around with ORDS 18 over the coming weeks. I’ll probably amend some of my existing ORDS articles as a result of that, and no doubt put out a new article on database authentication, for the lost souls that don’t look at the media examples, like me before Jeff told me to. đŸ™‚
Cheers
Tim…
You’ve probably seen that APEX 18.1 was released recently. This is just a quick note to say I’ve updated my Docker builds to include the latest versions of all the software including APEX. You can find the builds here.