Add support to consume return values from stored procedures

It would make sense to consume out parameters returned from a stored procedure. Since the R2DBC spec doesn’t define how to consume out params, we could map these onto a Row. R2DBC 0.9 allows defining out/in-out parameters so we could leverage Statement.bind(…) to register out parameter declarations. The invocation syntax would follow SQL Server defaults without having the driver to rewrite a stored procedure call.

Schema setup:

CREATE PROCEDURE test_proc
    @TheName nvarchar(50),
    @Greeting nvarchar(255) OUTPUT
AS

    SET NOCOUNT ON;  
    SET @Greeting = CONCAT('Hello ', @TheName)

SQL statement:

EXEC test_proc @P0, @Greeting OUTPUT

Java code:

MssqlConnection connection = …;

connection.createStatement("EXEC test_proc @P0, @Greeting OUTPUT")
    .bind("@P0", "Walter")
    .bind("@Greeting", Parameters.out(R2dbcType.VARCHAR))
    .execute()
    .flatMap(it -> it.map((row, metadata) -> {
        return row.get(0); // row.get("@Greeting");
    }))
    .as(StepVerifier::create)
    .expectNext("Hello Walter")
    .verifyComplete();

See: https://docs.microsoft.com/en-us/sql/relational-databases/stored-procedures/execute-a-stored-procedure?view=sql-server-ver15

[mp911de]

Re Parameters.out, this comes from the SPI and we could add there also a inOut factory variant. I think it would serve primarily the API and not really any functionality.

I was thinking the same thing. Also for clarity reasons, because a lot of RDBMS call the modifier INOUT or IN OUT or something similar. SQL Server is a bit special with their OUTPUT really meaning IN OUT and no OUT only parameter support.

Can you file either a SPI ticket or submit a PR if you like? The changes are limited to the Parameters type and basically a copy of the out methods with a separate type implementing In and Out interfaces.

Also, while I see that unifying OUT parameters and other types of Row simplifies the API and makes it more elegant as in my PostgreSQL example here: r2dbc/r2dbc-spi#27 (comment), this example shows that it would probably be useful to be able to formally expose whether a Row is a set of OUT parameters or a result set. Perhaps two different Segment subtypes possibly sharing some common API could help?

The idea to map out values to something Row-like goes into a proper direction. Thanks for this suggestion. Feel free to leave a comment on https://github.com/r2dbc/r2dbc-spi/pull/215. Coming up with a proper name for the interfaces might be a more difficult challenge than actually implementing it. Row extends <result-thing> for rows and <result-thing> for anything (including out params) that can be described with metadata and retrieved by name/index sounds seems a neat arrangement. On the Segment side, we can come up with a more fine-grained set of interfaces to represent row data and non-row data.

[lukaseder]

Can you file either a SPI ticket or submit a PR if you like? The changes are limited to the Parameters type and basically a copy of the out methods with a separate type implementing In and Out interfaces.

OK: https://github.com/r2dbc/r2dbc-spi/issues/216. I’ll provide a PR suggestion also.

Feel free to leave a comment on r2dbc/r2dbc-spi#215.

I will