Abstract from `ut_output_table_buffer`

[jgebal]

cli/api should not reference ut_output_table_buffer Instead, it should use ut_xxx_reporter.get_lines to reference the buffer. This way, different reporters can use different types of buffers and cli is abstracted from them.

[jgebal]

We might be forced to introduce additional constructors for reporters in utPLSQL. So that api/cli can create an in-line reporter like:

select * from table(ut_xxx_reporter(:reporter_id).get_lines())

Today, you would need to do it in two steps:

declare 
   l_reporter ut_output_reporter_base := ut_xxx_reporter();
begin
  l_reporter.set_reporter_id(:reporter_id);
  select * from table(l_reporter.get_lines());
end;

Alternatively, we could have a method to get reporter by id:

select * from table(ut_output_reporter_base.get_reporter(:reporter_id).get_lines());

This approach would be better as it wouldn't require changes on all reporters and wouldn't be a breaking change.

[pesse]

The current implementation of cli/java-api does only reference OutputBuffer in one place:

• Pre 3.1.0 implementation for compatibility (ut_output_buffer.get_lines_cursor(?))

There is, however, a check whether a reporter has output or not, which is basically a subclass-test on ut_output_reporter_base.

While the classes are still named "OutputBuffer" in java-api (something we should eventually change), they actually don't call any ut_output_buffer-API but call reporter.get_lines_cursor(). So we are already completely abstracted from actual output_buffer implementation of core.

The call for cursor is because we need to control the fetch size and my tests showed when implementing 3.1.0 that we can't control the fetch size when we are consuming a pipelined table functions directly.

At the moment I don't understand why we need in-line reporters the way it is described. Maybe we can talk about it.

[jgebal]

Oh. This is perfect then. You can consume from curtso - no issues. I thought you said we depend on output buffer - that is why I raised the issue.

I'll check to see if cli 3.1+ works well for separate buffers.

[pesse]

Yeah, that's what I thought from the top of my head because the classes are named OutputBuffer but are in fact not using it :)