Skip to content
This repository has been archived by the owner on Jun 24, 2020. It is now read-only.

R2DBC API: Expose product name #2

Closed
mp911de opened this issue Jun 7, 2018 · 3 comments
Closed

R2DBC API: Expose product name #2

mp911de opened this issue Jun 7, 2018 · 3 comments
Assignees
Labels
type: enhancement A general enhancement
Milestone

Comments

@mp911de
Copy link
Member

mp911de commented Jun 7, 2018

ConnectionFactory should expose a product name, ideally as part of driver-metadata. Optionally, the metadata could also expose server-metadata.

The product name is a useful detail when configuring SQLErrorCodeSQLExceptionTranslator.

@nebhale nebhale self-assigned this Jun 7, 2018
@nebhale nebhale added this to the 1.0.0.M4 milestone Jun 7, 2018
@nebhale nebhale added the type: enhancement A general enhancement label Jun 7, 2018
@nebhale
Copy link
Member

nebhale commented Jun 21, 2018

What would you think this should look like? Something like Map<String, String> getMetadata() or more specific Metadata getMetadata()?

nebhale added a commit to r2dbc/r2dbc-spi that referenced this issue Jun 21, 2018
This change updates the ConnectionFactory interface to return metadata.
Metadata is strongly typed in order to enforce a minimum set of data, but
implementations are strongly encouraged to extend this set of data to include
database-specific values that may be important to users.

[r2dbc/r2dbc-client#2]
nebhale added a commit to pgjdbc/r2dbc-postgresql that referenced this issue Jun 21, 2018
This change updates the implementation to support the new ConnectionFactory
Metadata.  The implementation is simple and only returns the name of the
database.  Further extension should be done to expose server-specific
metadata.

[r2dbc/r2dbc-client#2]
@mp911de
Copy link
Member Author

mp911de commented Jun 21, 2018

Let's stick with a Metadata getMetadata() to give value objects a meaningful name.

@nebhale
Copy link
Member

nebhale commented Jun 21, 2018

Sounds good. Pushed through with a static name on the PostgreSQL implementation. I'd expect to extend both the interface and PostgreSQL class with new, strongly named and typed methods based on feedback.

@nebhale nebhale closed this as completed Jun 21, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants