@olavloite Can you please request @elefeint for the review as well?
She's leading the Spanner R2DBC effort.

@olavloite Can you please request @elefeint for the review as well?
She's leading the Spanner R2DBC effort.

I'd love to, but apparently she is not a member of this repository, so I can't request her review. I would certainly appreciate her input, though.

I just want to say that I'm comfortable with this overall approach, and excited for the connection api to be made available for other libraries besides JDBC.

I would love for there to be something explicit about the level of support (and API non-breaking-ness) we are promising for this API. i.e. is every method exposed in the public interface going to be supported until the next major version? Do we want to claim less-than-that to start out with? It just seems important that we don't accidentally make this a fully supported/unchanging API without being clear.

@olavloite Can you explain the decision for not moving the connection API to a separate Maven module in the repo?

@meltsufin The honest answer is that I didn't think of that possibility as well :-). I automatically interpreted the suggestion to 'add it to the client library repository' as 'add it to the client library module'.

That being said, I would say that the following argument favors putting them together:

• Ease of versioning: The connection API only relies on the public API of the client library, so it could just have a dependency on the client library module. The two are however in real life somewhat more interconnected, and there have been changes in the past where a version of the connection API (or actually; the JDBC driver) depended on a specific minimum version of the client library. Users who would exclude the transitive client library dependency brought in by the connection API and import their own version of the client library would in those cases run into subtle bugs. (Of course one could argue that anyone who excludes a transitive dependency is responsible for knowing what they're doing.)

And the following would argue against putting them together:

• It adds build time to the client library.
• Anyone who imports the client library automatically also imports the connection API. This might confuse users as to which API to use.

I personally don't really feel very strongly either way, and I'm certainly open to additional arguments and views on this.

Regarding versioning, users should really be using the Spanner BOM the ensure compatibility between the Connection API and the Client Lib.

In addition to the benefits of separating into a separate module that you already outlined, another one is that it will ensure that the Client Library does not accidentally rely on something in the Connection API.

I guess the decision ultimately depends on how decoupled you want the Connection API to be from the client library.

Thank you! Looks good from my side.

To Cliff's point, perhaps we could have a README in the connection package explaining that this is internal only, "so please do not use this API by itself", and then relax this constraint over time if necessary?

I am out on Monday, so I'll get back to this on Tuesday.

Could we also add the @internalapi annotation to make it explicit in the code?

Edit: I realize that this might not work because it would mean that the JDBC driver can't use it.

Just my 2 cents on the two modules vs one module discussion. I feel that the connections API is strongly tied to the client library implementation and I can't think of any use cases where someone might want to use a different version of the connections API to that of the client library. So in terms the ease of us managing the modules/version and for users to not get into a confusing versioning situation, I'm in favor of having both being in the same module.

I haven't reviewed this line by line since this is PR is just moving code. @olavloite please feel free to merge.