Last year (ORDS version 24.1), we improved the workflow for the Database REST APIs we include with ORDS, specifically this endpoint (Docs) –
- Prior to ORDS 24.1 – a POST would create or clone the PDB, response comes back once operation is finished {SYNCHRONOUS}
- ORDS 24.1 and higher – a POST submits a DBMS_SCHEDULER job to create the PDB, immediate response with links to follow up for details {ASYNCH}
An Example –
I’ve done a Container (CDB) install of ORDS, and made my PDBs addressable, and have created an ORDS ADMIN database user in the CDB to make this possible. Full steps for that can be found here and here.
This is literally a bad example. It will FAIL fast, but it still shows the workflow. Our request succeeded, in that the task created, and we were given a link to follow.
If I follow the link –
I have no need to monitor this ‘page,’ because it’s already finished, and failed.
A working example –
I’ve corrected my mistakes, had a bad file path/pattern for the tablespace files, and run it again –
- make request
- request accepted, 202, with resource link
- follow the link, get the details, job is there…
- refresh, job has finished
I can confirm this if I look in the database –
But Jeff, I like the old way you had it before…
No worries, instead of running on ‘stable’ …
POST http://localhost:8181/ords/_/db-api/stable/database/pdbs/… call the version you prefer:
POST http://localhost:8181/ords/_/db-api/23.4/database/pdbs/A few notes
If you’ve built workflows using these APIs, the structure of the request payloads has changed a good bit, so you’re going to need to update how you handle the requests and the responses.
