Obscurities in DataPump API: OPEN procedure

A couple of weeks ago, I ranted on Oracle DataPump API. The post wasn't published because the wording needed polishing; I wanted emotions to calm down before posting it. Today I'm glad it wasn't published at that time: Oracle released version 11g and I'm happy to see some problems were addressed there. I'll publish the original post followed by 11g comments.

The original 10g post:

Don't know who projected Oracle DataPump API, but obviously these people didn't invest much brain in their work. Feels like they started with a robust vision, but as project's deadline approached, something has changed. Maybe their chief architect got replaced with a summer intern. Or perhaps they strengthened their team with a bunch of unexperienced new hires. Or maybe a desperate manager decided to keep team's spirit high by stuffing their fridges with beer.

Whatever the reason was, the results were demolishing. I'm trying to summarize today's findings, updating the series as new "discoveries" come up.

OPEN function

The definition is as follows:

DBMS_DATAPUMP.OPEN (
operation    IN VARCHAR2,
mode         IN VARCHAR2,
remote_link  IN VARCHAR2 DEFAULT NULL,
job_name     IN VARCHAR2 DEFAULT NULL,
version      IN VARCHAR2 DEFAULT 'COMPATIBLE'
compression  IN NUMBER DEFAULT KU$_COMPRESS_METADATA
) RETURN NUMBER;

"If you have a procedure with more than 5 parameters, you're probably missing some". Indeed. Parameter "compression" is so important, that programmers shall think of it every time they create a job. The choices are so broad, that we can't make up our mind. Yes, we want compression! No, we don't! Yes, we do! Developers spend hours on meetings and management schedules a golf session to decide whenever they want to use such an important option.

Get real. In 99.(9)% of the cases the fraction of metadata is so small, that nobody gives a dime. Everybody wants compression. Just turn it on and put it to a dusty corner - such as SET_PARAMETER() procedure.

Oh, wait - is it here because 11g will offer new compression mode - data compression? Still, everybody loves compression. Turn it on and move it away.

I will not rant on "mode" much. Perhaps implementation difficulties make it necessary to decide early in the game what kind of 5 exports we want. Perhaps the paradigm was inherited from old exp/imp. I don't know. All I know is that choosing mode imposes limitations on other API calls. More on this in metadata_filter section.

Comments after 11g release:

The comments are based on documentation published on OTN. Maybe the real package is different (this was the case with some API calls in the past) - 11g installation is still being downloaded, but specification of OPEN has changed: parameter COMPRESSION now belongs to SET_PARAMETER procedure.

<paranoid mode>Oracle is reading my mind !</paranoid mode>

Not quite. The default is still to compress metadata only.

Hope Oracle left old version of OPEN in the package to preserve compatibility. Removing it would break existing code (my code will be broken, good thing it is not yet released).

Later, after installing 11.1.0.6/Linux:
Parameter "Compression" is still in OPEN, it just gone undocumented.