Compliance requirements questions and typo in Javadoc

[Kuassi Mensah]

Hi,

Posting on behalf of our dev team
a) A couple of questions relative to the requirements for R2DBC compliance

1. should the Publishers returned by the implementations always support multiple subscribers?
2. should the Publisher returned by Statement.execute() repeat the execution for each subscriber? Or should the Publisher only initiate a single execution, and then emits the same Result to each subscriber?
   
3. The default mapping guidelines for BLOB columns is ByteBuffer, and String for CLOBs columns.
   If the driver must perform a database call to obtain BLOB/CLOB contents, then the call to Row.get(..) which maps to a ByteBuffer/String must  block until the database call completes. Is this expected and acceptable?

b) We believe there is a typo in the Row javadocs for get(int) and get(int, Class).
They are specified to throw IllegalArgumentException if the int argument is null, but the primitive  type int can not be null (rather  0 if un-initiliazed).

Best, Kuassi

[Mark Paluch]

Hi Kuassi,

Thanks for your message. Regarding your questions about compliance:

1. Publishers are not expected to support multiple subscribers in general. While multiple subscribers can be supported where it makes sense (Connection.setAutoCommit(…), Connection.beginTransaction()), it's not a requirement.

2. No, Statement.execute() should support a single subscriber only. Otherwise, the same statement could be executed multiple times. Moreover, stream-like parameters (like BLOB/CLOB) of a parameterized query would have been already in a consumed state so that the driver cannot construct the query.

3. This is because Oracle uses locators to obtain large objects? I think that's something worth discussing. We hadn't had such a case previously. The spec to use String/ByteBuffer came from the fact that the currently available drivers don't have a dedicated BLOB/CLOB type. Instead, they materialize the content directly which makes consumption of large objects convenient. I would recommend to not block in these cases. For the time being, how about returning R2DBC's Blob/Clob type instead? It's different from what the spec mandates, but we should do something that makes sense.

Can you provide a bit more details for which data types the R2DBC spec would require your driver to block? Maybe we can relax the spec in those areas and be more specific where BLOB/CLOB should map to R2DBC's Blob and Clob types without breaking too many things.

Thanks for letting us know about the documentation mismatch. I filed a ticket [0] to fix it.

Cheers, 

Mark

[0] https://github.com/r2dbc/r2dbc-spi/issues/182